Arithmetic processing device, inter-object communication method, and robot6728598Abstract An arithmetic processing device for inter-object data communication has an object manager for connecting objects so as to enable exchange of data between the objects, and a connection data supplying unit for supplying the object manager with connection data necessary for achieving the connection between the objects. Disclosed also are an inter-object communication method and a robot incorporating the arithmetic processing device. The robot may be designed to enable a user to replace parts thereof, thus changing the robot configuration. The robot preferably includes a part detection unit for detecting parts attached to the robot, and outputting a part detection result in accordance with the detection. An information storage unit stores information corresponding to the part detection result for each configuration obtained by replacement of the parts. A software changing unit revises robot-controlling software in correspondence with a changed configuration, based on a comparison of the part detection result with the information stored in the information storage unit. A controller controls general robot operations in accordance with the revised software. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
Design Label (CPC Primitive Location (1)
Information or Design Label);
. . .
)
The following expression (2) describes a virtual label. The virtual label is constituted by a design label, Constituent elements (CPC Primitives), and position information (CPC Coordinate Locator) of the constituent elements (CPC Primitives).
Virtual Label ( (2)
Design Label:
CPC Primitive:
CPC Coordinate Locator:
)
The following expression (3) describes a composite label:
Composite Label ( (3)
Composite Label;
or/and Design Label;
or/and Virtual Label:
)
To this end, the design robot traces the tree structure based on the constituent element information identified by the connection information delivered thereto. If the position information (CPC Coordinate Locator) defined in the virtual label exists at a portion of the tree structure near the end thereof, the design robot substitutes this virtual label for a design label and sets the thus-defined design label as being valid. Accordingly, in this embodiment, access is made to the design file based on the connection information, whereby the current robot configuration (e.g., four-legged or wheeled configuration) can be differentiated and, at the same time, various data necessary for updating the configuration-dependent software can be acquired. FIG. 8 is a flowchart illustrating the above-described process conducted by the design robot. Upon receipt of the connection information from the virtual robot, the design robot accesses the design file in step SP2 based on the connection information, whereby the current configuration of the robot 1 is identified. Next, in step SP3, the design robot compares the constituent element information (CPC Primitive Location Information) contained in the connection information received from the virtual robot with the CPC Primitive Location Information contained in connection information held by the design file. In step SP4, based on the result of the comparison made in step SP3, the design robot accesses the design file so as to detect the design label that defines the objects corresponding to the current configuration and the data necessary for rebuilding the inter-object communication. Next, in step SP5 the design robot accesses a Connection File 160 (see FIG. 7) based on the detected design label, and detects Connection Data corresponding to the label, whereby data are acquired that are necessary for identification of the objects and re-building of the inter-object communication. The Connection File is a file that stores Connection Data in relation to the label. The Connection Data are data that are necessary for identification of the objects and re-building of the inter-object communication. In step SP6 the design robot delivers the Connection Data to the object manager, thereby delivering an instruction for updating the configuration-dependent software. This completes the routine. FIG. 9A is a list which describes part of the design file. In this design file, DRX indicates the configuration of the robot 1, wherein "4Legged" is a description indicative of the four-legged configuration, while "Head", "RightFrontleg", "LeftFrontLeg", "RightRearLeg" and "LeftRearLeg" respectively indicate the head, right foreleg, left foreleg, right rear leg and the left rear leg of the robot. Thus, the first code sentence signifies that the four-legged configuration is composed of a head, right foreleg, right rear leg and a left rear leg. In the second code sentence, "Wheel" indicates the wheeled robot configuration. As compared to the first sentence, it is understood from the second sentence that the wheeled robot configuration is constituted by a head, right foreleg, left foreleg, right rear wheel and a left rear wheel. The third code sentence describes that a camera link is provided on the head, whereas the fourth code sentence describes the virtual label of the camera link. In the fifth code sentence onwards, items of position information (CPC Coordinate Locator) are described in the form of a tree, for the components such as the right foreleg, left foreleg, and so on. Referring to FIG. 9B, a list describing part of the connection information (CPC Connection Information) is shown. In this embodiment, the connection information is described in the form of text data, as in the case of the design file. In the description shown in FIG. 9B, "joint" indicates an interface. Thus, the portion indicated as "joint" constitutes an interface where different constituent elements are connected. Lines 2 to 5 of the description show that a television camera is connected via five hubs, each hub designated as "CO". It is thus understood that the connection information shown in FIG. 9B coincides with the description of the four-legged configuration explained above in connection with FIG. 9A. Expression (4) below exemplifies part of the Connection File 160. The Connection File is written in the form of text data. The first and second code sentences of expression (4) respectively describe the objects corresponding to the four-legged and wheeled robot configurations, as well as data necessary for building inter-object communications. More specifically, the first sentence describes an object name "MoNet" as a service name and data format MoNetOutData. Further, subsequent to "0" that indicates an observer, an object name "MoNetReplay" as a service name and data format MoNetOutData are described. Descriptions of subject, observer, data format and so on are made in subsequent lines.
DRX 4Legged ( (4)
S.MoNet.MoNetOutData . . . ,O.MoNetRePlay.MoNetOutData . . .
S.MoNet.MoNetOutData . . . ,O.WalkingPatternGenerator,MoNetOutData . .
.
)
DRX Wheel (
S.MotionGenerator.MCData . . . , O.MotionReplay?.MCData . . .
S.MotionConverter.MCData . . . O.Wheel
)
Thus, when the design file as shown in FIG. 9A is used, the design robot operates based on the description of the first sentence reading DRX 4Legged and extracts Connection Data that are described within parentheses ( ) that appear subsequent to DRX 4Legged, and delivers the extracted connection data to the object manager, whereby the configuration-dependent software is revised. FIG. 10 is a diagram illustrating processing operations performed by the object manager, virtual robot and the design robot at the time of boot. The robot 1 commences boot processing in response to the power supply being turned on, or to a resetting instruction. In the boot processing, objects are loaded from a file so as to build up configuration-dependent software. Concomitantly, internal variables of the object manager are initialized. Subsequently, the object manager delivers "Do Initialize" ("DoInit") to each object. In response to DoInit, an inquiry entry (Entry) of each object is registered in the object manager, whereby inter-object communications are built up in the robot system software layer. Next, the object manager delivers "DoStart" to the virtual robot and then to the design robot, whereby the virtual robot and the design robot begin to operate. Consequently, connection information is generated by the virtual robot and, upon request by the design robot, the connection information thus generated is delivered to the design robot, whereby Connection Data is generated. The Connection Data thus formed is delivered to the object manager, whereby configuration-dependent software is built up in accordance with the Connection Data. A shut-down process is executed as follows: the object manager delivers a "DoStop" command to each object. In response to this instruction, each object ceases to operate by sending an error message responsive to all the requests. Then, the object manager sends to each object "DoDestroy", so that each object releases the resource that has been used by the object, and is set to a stand-by condition after deleting its entry that has been registered in the object manager. Thus, robot 1, even when started up after a reconfiguration to a different robot configuration, can operate safely under the control of software suitable for the new robot configuration. In the case of a so-called Plug-In or Plug-Out condition, a robot part is newly detected to be plugged into, or unplugged from, the robot main body. When this occurs, the object manager delivers a "DoStop" command to each object, as shown in FIG. 11, whereupon each object terminates its operation after relaying "error" to all the requests. Subsequently, as in the case of the boot, the object manager delivers DoStart to the virtual robot and then to the design robot. As a consequence, the virtual robot generates connection information which is delivered to the design robot. The design robot then generates Connection Data based on the connection information, whereby a configuration-dependent software is built-up. Thus, even when the configuration of the robot 1 is dynamically changed by Plug-In or Plug-Out, the robot 1 is controlled by software suitable for the robot configuration after the change. In the event of depletion of the battery 17, the DoStop and DoStart processing operations are repeated as in the case of Plug-In and Plug-Out, in response to a state change request given by the battery manager. As a result, the state of robot 1 is changed to a mode in which the clock frequency is lowered and operations of unnecessary devices are suspended, while the power supply is switched over to the button cell 29. Conversely, when the battery 17 that has been charged up is mounted, the state is changed into a mode in which the clock frequency is increased and the operations of the devices are commenced by the power supplied from the battery 17. IV. Processing by Object Manager In accordance with the information provided by the design robot as described above, the object manager 120 reassembles the objects that constitute the configuration-dependent software, whereby the configuration-dependent software is revised and updated. More specifically, the object manager loads and unloads objects in accordance with the information received from the design robot, and rebuilds the inter-object communications so as to correspond to the unloading and loading of the objects, thereby revising and updating the configuration-dependent software. If the build up of inter-object communications requires that the object names have been registered in the object manager, independency of each object is undesirably impaired so that a plurality of types of objects have to be prepared. To eliminate this problem, in the illustrative embodiment of the present invention, the object manager builds up the inter-object communications based on the Connection Data output from the design robot, thereby maintaining independency of the objects. A description of inter-object communication will now be presented, which is applicable to any of the objects within robots or other devices of the present invention. To simplify the description, specific object names will not be presented. Also, it is assumed that the inter-object communication is executed in an asynchronous manner. Referring to FIG. 12, there is shown a diagram schematically illustrating the basic structure of inter-object communication between two objects that can be used in embodiments of the invention. In the example presented, the inter-object communication is executed by using "Ready" and "Notify" commands, so as to prevent delivery of data in excess of the processing capacity of the object that received data (Object B in this case). In FIG. 12, object A sends data from a class 0 subject as a member of object A to a class 0 observer which is a member of object B, whereby the "method" of object B is invoked. The delivery of the data from the subject to the observer is conducted only when the "Ready" signal is received from the observer. The Ready signal is delivered once for each data transmission. Thus, object B as the observer becomes ready to receive subsequent data only after processing of the received data is completed. FIG. 13 is a diagram schematically showing the basic arrangement for inter-object communication in a multi-observer system. In this case, object A serving as the subject can deliver data either to all the observers or only to a selected observer identified by the object ID. The delivery of data in this multi-observer system is conducted only to the observer that issues the Ready signal, as in the previous case of FIG. 12. When an object ID identifying an object and a selector number (selector) identifying a method are given, the identified object(s) starts entry of the designated method and delivers the desired data to a specified observer. FIG. 14 is a diagram schematically showing the basic structure of inter-object communication in a so-called multi-subject system. In this case, both objects A and B serve as subjects, while the object C alone serves as the observer. Thus, the observer can receive data from each of a plurality of subjects and, each time the data is received, a method for processing the data is also invoked. The observer can select the subject by issuing the Ready signal only to a specific subject that is identified by the subject ID, so that it can receive only the required data. Thus, in the illustrated embodiment, at least for the objects which belong to the configuration-dependent software layer, the inter-object communication is executed by using the Ready signal and the notification signal (Notify), as described with reference to FIGS. 12 to 14, and a multi-observer or multi-subject system can be implemented as desired to connect other objects. Namely, an object that has a plurality of observers is equipped with connect entries of the same number of observers. FIG. 15 illustrates the relationship between an object manager and each of a plurality of objects. The objects exchange data with each other by means of the object ID and the method specified by the selector number (Selector). In each object, selector numbers "0" to "3" are assigned to basic methods, regardless of the subject or observer corresponding to the object. In this example, the selector number "0" is assigned to "Do Initialize" (DoInit). Each object is initialized when the DoInit method is started. The selector number "1" is assigned to "DoStart". Each object starts to operate when DoStart is started. Conversely, when the "DoStop" method (selector number "2") is started for a particular object, that object ceases to operate. When "Do Destroy" (selector number "3") is invoked for a specific object, that object releases the resource. Further, each object is arranged to communicate, by means of return values, names of services made by the observer, selector numbers and so forth, in compliance with requests given by the object manager and other objects. Accordingly, in the illustrative embodiment of the invention, loading and unloading of objects and subsequent rebuilding of inter-object communication can be conducted by the object manager, based on the Connection Data given by the design robot. Expression (5) below contains exemplary Connection Data given by the design robot, described in the form of text data by using a colon as a demarcation between the name of a service of the subject and the name of a service of the observer. Regarding the subject, the description begins with "S" that indicates the subject, followed by "FooB" which is the object name, "Image" which indicates the data form, and "RightCamera" which is the name of the constituent element. As to the object, the description begins with "0" that indicates the object, followed by "FooA" which is the object name, "Image" which indicates the data form, and "RightCamera" which is the name of the constituent element. S.FooB.Image.RightCamera:O.FooA.Image.RightCamera (5) The object manager, when loading an object, detects the name of the object to be loaded based on the description of the Connection Data. Further, the object manager loads the object of the detected object name from a predetermined file, while preserving a stack memory (stack) and a heap memory (heap). The object manager also serves to acquire the object ID from an operation system (OS) and records this object ID together with the object name described in the Connection Data. The object manager is arranged to execute the above-discussed processing operations such as DoInit, DoConnect and DoStart (which are explained further below) by using the object ID registered in the described manner. The DoInit processing is as follows: based on the acquired object IDs and the above-mentioned selector numbers, the object manager calls DoInit for all the objects acquired through the loading. In response to the call of DoInit, each object initializes its internal variables. Consequently, each object is initialized in the object manager. In this initialization processing, the object manager operates so as to register the entry (Control) of each object as a subject and the entry (Connect) of the object as an object, based on the information provided by each object. This registration is constructed corresponding to the description of the subject and the object in the Connection Data, i.e., by the names of the object and subject. The operation executed in accordance with the DoConnect command is as follows: based on the registration made in the DoInit operation, the object manager operates to communicate the entries (Connect) of the objects having observers of the subject (Object ID) ID and the entry (Control) of the subject to be registered. Each object receiving this information invokes the subject corresponding to the informed subject ID and the entry (Control), and the entry (Notify) is connected to and registered in the invoked subject. The subject requested to be registered sends the Ready command to the observer, whereby the observer is connected to the corresponding subject. Inter-object communication is thus established between the observer and the subject. In this operation, the object manager informs the observer notified by the Connection Data of the subject ID (object ID) and the entry (Control) of the corresponding subject. In this embodiment, therefore, each object can be developed without requiring any explicit indication of objects to which the developed object is to be connected, and is connectable as required to various types of objects in accordance with the instruction given by the object manager. It is thus possible to ensure higher degree of independency of each object relative to the known art. Concomitantly, the inter-object communication can be built up by the object manager in accordance with the Connection Data, so that the configuration-dependent software can be easily and freely revised and updated in conformity with the current robot configuration. The operation in accordance with the DoStart instruction is as follows: the object manager sends the selector number "1" to each object (where "1" represents the DoStart instruction in this example). Each object, when it has an observer, responds by sending "Ready" to the subject, by using the subject ID and the entry (Ready) that have been acquired by the DoConnect operation. The object thereby becomes ready to receive data from the corresponding subject, and the configuration-dependent software starts to run. In the case of a multi-observer arrangement, the subject sends data, e.g., a sensor output, to the observer that is issuing "Ready" among the registered observers. This observer sends "Ready" when it becomes ready to receive subsequent data after completion of processing of the received data. In contrast, in case of "Shut Down", "Plug-In", "Plug-Out" and "State Change", the connection data sent from the design robot differs from the registered content that has been previously sent by the design robot. In this case, the object manager sends the DoStop instruction to each object, by sending the selector number "2". In the meantime, the observer cancels the entry (Ready). In the "DoDisconnect" processing, the object manager serves to cut the communication connection between the subject and the observer. More specifically, the object manager sends the "DoDisconnect" message to the entry (Connect) of the observer, so that the observer causes the corresponding subject to issue a disconnection request (Remove Observer), thereby cutting the communication connection. The "DoDestroy" processing is as follows: the object manager sends the DoDestroy message to the corresponding object, by sending the above-described selector number "3", thereby destroying this object. The destruction is conducted by executing dismissal of the registration that was made in the "Do Initialize" (DoInit) processing. In the "Object Unload" processing, the object manager opens the stack memory and the heap memory for the object that was destroyed by the DoDestroy processing, thereby unloading the object. At the same time, the subject ID and the subject name that were registered at the time of loading are deleted. Upon receipt of, for example, the Connection Data from the design robot through the described control, a control sequence is executed down to DoStart as shown in FIG. 16. More specifically, the object manager is started in response to a message that carries the Connection Data, and operates to load, for example, an object A and an object B that are described in the Connection Data. In this case, the loading of object A and object B are executed in accordance with a system command of the operation system. The object manager acquires the object IDs of objects A and B and registers the acquired object IDs. Subsequently, the object manager starts "Do Initialize" (DoInit) of both object A and object B, based on the acquired object ID and the selector number "0", whereby the entry (Control) as a subject and the entry (Connect) as an object are acquired from objects A and B and registered. Then, "DoConnect" of object A (serving as the observer) is initiated based on the registered entry (Connect), whereby object A is connected to object B (the latter serving as the subject). It is thus possible to build up inter-object communication based on the Connection Data. The object manager then commences DoStart of objects A and B. FIG. 17 is a timing diagram showing the sequence which begins with the DoStart command. Object A, object B and other objects are started in response to the DoStart message sent by the object manager. These objects then execute inter-object communications by using the Ready and Notify messages (described previously). More specifically, object A sends the Ready message to the Ready entry of object B, and object B sends a message to the Notify entry of object A, whereby data is sent from object B to object A. If the message has not yet been sent from object A to the Ready entry of object B as the data is being processed by object A, the Notify entry of object A by object B is registered, and the sending of the data from object B is executed only after the Ready entry of object B by object A. In this inter-object communication, therefore, sending of data in excess of the data processing capacity of object A is prevented. FIG. 18 is a timing diagram showing the sequence which is followed at the time of "Plug-In", "Plug-Out" and "State Change". If the Connection Data received from the design robot differs from the registered contents previously received from the design robot, the object manager sends the DoStop instruction to all the objects, thereby ceasing the operations of all the objects. More specifically, object A and object B dismiss the entries (Ready) so as to prohibit commencement of their "Notify" entries. Upon completion of the "DoStop" of all the objects, the object manager sends "DoDisconnect" to object A so as to disconnect this object from other objects, and starts "DoDestroy" of this object A, whereby the resource of object A is released and the registration of object B that was made by DoInit is dismissed. When the "DoDestroy" processing is finished for the objects that are to be destroyed, the object manager executes "unload" in accordance with a system command of the operation system. More specifically, a "destructor" of the object of concern is invoked. In this case, the "destructor" of the object A is invoked, so that the registration of the object A that was made at the time of loading is dismissed. Further, the object manager opens the stack memory and the heap memory, thereby completing unloading of object A. Subsequently, the object manager gives an instruction to load an object C, in accordance with the Connection Data. Thus, DoInit, DoConnect and DoStart commands are sequentially started in the same manner as that described above with reference to FIG. 16. It is thus possible to alter the configuration composed of object A and object B into a configuration composed of object B and object C, without any compiling during the operation. V. Registration of Object by Associative Memory FIG. 19 schematically depicts object A and object B under the Connection Data expressed by the foregoing expression (5). The object manager holds and records the Connection Data in an associative memory (or memories) and, when registering the objects by starting "Do Initialize" (DoInit) of the objects, registers the objects in the associative memory based on the description of the Connection Data. In the example of FIG. 19, the object name of object A serving as the observer is "FooA", the object name of object B serving as the subject is "FooB", the data form is "Image" and the name of the sub is "RightCamera". Thus, the Connection Data between the subject and the object are expressed by: (S.FooB.Image.RightCamera:O.FooA.Image.RightCamera), using a colon as the demarcation between the service name of the subject and the service name of the observer. Upon receipt of this Connection Data from the design robot, the object manager accumulates the description of the subject service name (S.FooB.Image.RightCamera) in the associative memory 1, using as a key the description of the observer service name (O.FooA.Image.RightCamera), as will be seen from FIG. 20. Each object then operates in response to the DoInit command to communicate the registration entry of the object manager of the service name and the selector number. The object manager stores the service name and the selector number thus communicated in an associative memory 2, thereby registering each object. More specifically, object A as the observer communicates the service name of a description which is the same as the description (O.FooA.Image.RightCamera) of the observer service name in the Connection Data and communicates also the selector number of the connection entry. It is assumed here that the selector number for the object A is "5". The object manager operates so as to store in the associative memory 2 the object ID and the selector number (OID, Entry)=(2,5) of the object A, using as a key the description (O.FooA.Image.RightCamera) of the observer service name in the connection data (Connection Data), as will be seen from FIG. 21. The object ID of the object A has been informed as being a value "1", from the operation system. In the meantime, object B as the subject communicates the service name described in conformity with the description of the subject service name (S.FooB.Image.RightCamera) in the Connection Data, as well as the selector number of the connection entry. It is assumed here that the selector number for object B is "5". The object manager operates so as to store in the associative memory 2 the object ID and the selector number (OID, Entry)=(1,5) of the object B, using as a key the description (S.FooB.Image.RightCamera) of the subject service name in the Connection Data, as shown in FIG. 21 together with the description concerning object A. The object ID of object B has been designated as being a value "2", from the operation system. When "DoConnect" is executed, in the object manager, the description concerning the subject and the description concerning the object of the Connection Data are separated. More specifically, in the object manager, the Connection Data is divided so as to correspond to the key (O.FooA.Image.RightCamera) stored in the associative memory 1 and one of various descriptions (O.FooA.Image.RightCamera) stored in the associative memory 1 by means of the key (O.FooA.Image.RightCamera). Further, the object manager makes retrieval through the associative memory 2, based on the separated descriptions, thereby detecting the object ID and the selector number (1,5) of the corresponding observer, as well as the object ID and the selector number (2,5) of the corresponding subject. The object manager then sends the message of the object ID and the selector number (2,5) to the object ID and the selector number (1,5), thereby starting the connector entry of the observer, and informs this connector entry of the information of the subject composed of the object ID and the selector number (2,5). The control entry of the subject by the object ID and the selector number (2,5) is then started by the above-mentioned connector entry, and the object ID and the selector number (1,6) ("Notify", in this case) of the observer are registered in the started control entry. The observer acquires the selector number of "Ready" by the return value, and registers this selector number. Thus, in the object manager, connection between the objects is established by using the associative memories 1 and 2. When the connection between the objects is established as described, the object manager serves to store in an associative memory 3 the description (S.FooB.Image.RightCamera) concerning the subject in the Connection Data, by using as a key the description (O.FooA.Image.RightCamera) concerning the object. Further, the object manager operates to delete from the associative memory the description (S.FooB.Image.RightCamera) concerning the subject that has been stored by using as the key the description (O.FooA.Image.RightCamera) concerning the observer. Thus, the object manager ensures that the observer and the subject, with inter-object connection established therebetween by the description corresponding to the Connection Data, are registered in and held by the associative memory 3. To this end, when executing "DoDisconnect", the object manager performs a reverse operation to the described "DoConnect" operation: namely, it breaks the connection, deletes the description in the associative memory 3 and stores this description again in the associative memory 1, while deleting the corresponding description in the associative memory 2. It is assumed here that Connection Data expressed by the following expression (6) is delivered from the design robot, as a result of the revision of the configuration-dependent software: S.FooB.Image.RightCamera:O.FooC.Image.RightCamera (6) This Connection Data describes a change of the observer from the object B to the object C. In this case, the object ID and the selector number (1,5) that has been set in the observer by the key (O.FooA.Image.RightCamera) are detected from the associative memory 2. Then, the "DoDisconnect" instruction is given to object A serving as the observer, by means of the object ID and the selector number (1,5) and, at the same time, corresponding description (descriptions of object A and object B serving as the observer and the subject, respectively) in the associative memory 2 is deleted. Further, the corresponding description is deleted from the associative memory 3 and recorded again in the associative memory 1. Namely, the object manager operates to delete from the associative memory 2 the descriptions of the object IDs and the selector numbers that have been stored by means of the keys (O.FooA.Image.RightCamera) and (S.FooA.Image.RightCamera). Accordingly, the object manager can dynamically change the objects. Robot Operation In accordance with the foregoing description, the robot 1 shown in FIG. 1A can have the four-legged configuration with four legs constituting the moving unit 3 attached to the main part 2. With this configuration, robot 1 can walk using the four legs, by means of motors incorporated in the legs. Robot 1 can also have the wheeled configuration with the rear legs substituted by wheels. The wheels are preferably power driven to effectuate the robot movement. As described previously in connection with FIG. 2, the operations of the moving unit 3 and other parts are controlled in accordance with control instructions given by the central processing unit 22, based on the outputs from sensors that are arranged on the robot components 24, 25, 26 (e.g., legs, wheels, arms, etc.) as well as information obtained through various information acquisition means provided on the head 2A. Returning to FIGS. 3 and 4, software of the object-oriented commanding layer operates various device drivers on the commanded device driver layer, thereby executing the above-described control. In this control, the robot system software of the commanding layer commanding the device driver layer detects various parts connected to the serial bus by means of the virtual robot. The virtual robot supplies the design robot with connection information (CPC Connection Information) which indicates what types of components are connected (e.g., legs or wheels) and how these components are connected to complete the robot 1. Consequently, the current configuration of the robot can be identified by the devices connected to the serial bus, whereby the parts or components to be controlled are definitively identified. In robot 1, the software of the layer which commands the robot system software 101 is revised and updated in accordance with the connection information, whereby the overall control of the robot is performed by the software which best suits the current robot configuration. To this end, in robot 1, the design robot object 124 of the robot system software 101 compares a design file which has been formed by attaching labels to constituent element information (CPC Primitive Location Information) of the respective parts constituting each robot configuration with the connection information provided by the virtual robot, and selects objects that conform to the current robot configuration. The configuration-dependent software is then revised by using the selected objects, as described previously with reference to FIGS. 7 and 8. Thus, the software is updated easily to conform to the current robot configuration, so that the overall action of the robot can be adequately controlled. The software of the commanding layer is divided into the configuration-independent software which has no dependency on the robot configuration, and the configuration-dependent software which does depend on the robot configuration. Data that are handled by the configuration-independent software independently of the robot configuration are converted by the configuration-dependent software into data corresponding to the current robot configuration, and the thus converted data are exchanged between the configuration-dependent software and the robot system software. Thus, only the configuration-dependent software is revised and updated. Thereby, the revision of the software can be easily implemented. Further, the virtual robot generates the constituent element information (CPC Primitive Location Information) described in the form of text data, as shown in FIGS. 9A and 9B. The design file also is described in the form of text data. Therefore, the present invention is easily adaptable to a variety of robot configurations that may be developed in the future. In robot 1, the update of the software is executed by the object manager which reassembles the objects constituting the configuration-dependent software. For instance, at the time of the booting, the design robot informs the object manager of the Connection Data which instructs to connect the objects conforming to the current robot configuration, so that the object manager operates to load the objects designated by the Connection Data. After initialization of the loaded objects, the object manager connects the subject and the observer in accordance with the Connection Data to enable data exchange there between, whereby the configuration-dependent software is built up by the objects that suit to the current robot configuration. In robot 1, therefore, the software can be built-up by the objects that are designed without envisaging any object to be connected. In addition, the Connection Data is generated in accordance with each robot configuration, enabling easy set-up of software suitable for the current robot configuration. It is also to be appreciated that the revision of the software can be made without requiring any re-compiling and re-linking. Consequently, in the robot 1 of the present invention, the objects can have independency dramatically enhanced over the prior art. This means that a variety of software can be readily and quickly obtained to handle a versatile change in the robot configuration. Via suitable setting of the Connection Data, it is possible to establish inter-object communication between a single object and a plurality of other objects. The design file stores a plurality of sets or combinations of Connection Data, and the design robot selects one set of Connection Data from the design file and delivers the selected file to the object manager. Various software versions corresponding to various robot configurations can easily be implemented by suitably preparing the designs to be stored in the design file. It is also possible to easily revise the Connection Data because the Connection Data is preferably written in the form of text data. A change in the configuration of the robot 1 is detected by the virtual robot. The virtual robot informs the design robot of the connection information (CPC Connection Information) concerning the robot configuration after the change. The design robot then compares the connection information with designs in the design file, and generates Connection Data corresponding to the new robot configuration, based on the result of the comparison. In accordance with the Connection Data thus formed, the object manager unloads the objects that have become unnecessary, while loading objects that have become necessary as a result of the change of the robot configuration, whereby the objects constituting the configuration-dependent software are reassembled. These objects are connected in accordance with the Connection Data so as to be mutually communicable, whereby the configuration-dependent software is updated. Thus, in the robot 1 of the present invention, the configuration-dependent software can easily be updated adapting to the current robot configuration, while allowing the configuration-independent software to continue to run. The software update can also be performed to change the mode of operation into a power saving mode. Advantages of the Described Embodiment As will be understood from the foregoing description, the robot of the present invention can have various configurations through replacement of the robot components. The objects are connected by the object manager in accordance with the connection data, so as to be mutually communicable. Consequently, each object can have a greater degree of independency than those in the prior art, which in turn permits easier revision of the software in accordance with the current robot configuration. It is also to be noted that the revision of the software can be easily achieved without the need for recompiling and re-linking. Further, by suitably setting the Connection Data, it is possible to establish inter-object communication between a single object and a plurality of other objects. Connection of the objects can be easily achieved because the Connection Data identifies the objects to be involved and the type of data to be exchanged. The connection of objects is achieved in accordance with Connection Data selected from among a plurality of sets, combinations or types of connection data stored in the design file. Therefore, by preparing a suitable design file, it is possible to readily provide different versions of software adapting to a variety of robot configurations. When the robot configuration is changed, disconnection and connection of objects are conducted such that the objects that have been employed for the old robot configuration are disconnected and the objects to be employed for the new robot configuration are connected to achieve inter-object communication in accordance with the Connection Data. It is therefore possible to update the software adapting to the new robot configuration, without requiring operation of the software to be suspended or terminated. It is also to be understood that the software can be revised in conformity with the robot configuration, based on the Connection Data that are provided by the virtual robot capable of detecting the robot components employed. Further, since the Connection Data is described in the form of text data, it is possible to easily and promptly generate software adapting to the current robot configuration. Moreover, the inter-object communication is performed through exchange of messages "Ready" and "Notify", so that exchange of data at a rate exceeding the processing capacity of the objects can be avoided. Other Embodiments In the embodiment heretofore described, the selector numbers of "DoInitialize" and so forth have been set beforehand. This, however, is not exclusive and the arrangement may be such that the selector number is set when, for example, "DoInitialize" of the object is started in accordance with the Connection Data. It is also possible to arrange such that the selector number is set when, for example, "DoInitialize" of the object is started in accordance with the content of registration of the object in the object manager. In the described embodiment, re-assembling of the objects in accordance with the Connection Data is executed only for the configuration-dependent software. This also is illustrative and the present invention may be modified such that the entire software is revised in accordance with the Connection Data, or such that only the device driver layer is revised in accordance with the Connection Data. In the foregoing description, the robot embodying the present invention operates based on the observer pattern constituted by observer and subject. This also is illustrative and the invention can also be embodied in another type of robot such as a robot relying on a sever-client system. In such a case, a client receives the Connection Data as input data and connects the data to a server, whereby the system can be implemented without requiring the server name to be described in the source code. Thus, the client and the server of the server-client system constitute respective objects. Although in the described embodiment the inter-object communication is performed based on exchange of the "Ready" and "Notify" messages, the present invention can widely be applied to various types of inter-object communication that employ a variety of data exchange methods. As will be understood from the foregoing description, according to the present invention, it is possible to enhance the independence of objects over the known arts, by the feature in which the objects are connected in accordance with connection data, so as to be mutually communicable. While the present invention has been described above in reference to preferred embodiments thereof, it is understood that these embodiments are merely exemplary and that one skilled in the art can implement many changes to the disclosed embodiments without departing from the spirit and scope of the invention as defined by the appended claims.
|
Same subclass Same class Consider this |
||||||||||