WO2009124951A1 - Architecture de controle - commande d'un robot mobile utilisant des membres articules - Google Patents

Architecture de controle - commande d'un robot mobile utilisant des membres articules Download PDF

Info

Publication number
WO2009124951A1
WO2009124951A1 PCT/EP2009/054177 EP2009054177W WO2009124951A1 WO 2009124951 A1 WO2009124951 A1 WO 2009124951A1 EP 2009054177 W EP2009054177 W EP 2009054177W WO 2009124951 A1 WO2009124951 A1 WO 2009124951A1
Authority
WO
WIPO (PCT)
Prior art keywords
computer
mobile robot
command
bytes
robot according
Prior art date
Application number
PCT/EP2009/054177
Other languages
English (en)
Inventor
Julien Serre
Brice Marnier
Jérôme MATARD
Original Assignee
Aldebaran Robotics
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Aldebaran Robotics filed Critical Aldebaran Robotics
Priority to EP09731189A priority Critical patent/EP2262623A1/fr
Priority to US12/736,456 priority patent/US9327400B2/en
Priority to CN200980119536.2A priority patent/CN102046337B/zh
Priority to JP2011503428A priority patent/JP5849345B2/ja
Publication of WO2009124951A1 publication Critical patent/WO2009124951A1/fr
Priority to US15/082,700 priority patent/US10022862B2/en

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B25—HAND TOOLS; PORTABLE POWER-DRIVEN TOOLS; MANIPULATORS
    • B25J—MANIPULATORS; CHAMBERS PROVIDED WITH MANIPULATION DEVICES
    • B25J9/00—Programme-controlled manipulators
    • B25J9/16—Programme controls
    • B25J9/1602—Programme controls characterised by the control system, structure, architecture
    • B25J9/161—Hardware, e.g. neural networks, fuzzy logic, interfaces, processor
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/18—Numerical control [NC], i.e. automatically operating machines, in particular machine tools, e.g. in a manufacturing environment, so as to execute positioning, movement or co-ordinated operations by means of programme data in numerical form
    • G05B19/414—Structure of the control system, e.g. common controller or multiprocessor systems, interface to servo, programmable interface controller
    • G05B19/4141—Structure of the control system, e.g. common controller or multiprocessor systems, interface to servo, programmable interface controller characterised by a controller or microprocessor per axis
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/18—Numerical control [NC], i.e. automatically operating machines, in particular machine tools, e.g. in a manufacturing environment, so as to execute positioning, movement or co-ordinated operations by means of programme data in numerical form
    • G05B19/414—Structure of the control system, e.g. common controller or multiprocessor systems, interface to servo, programmable interface controller
    • G05B19/4148—Structure of the control system, e.g. common controller or multiprocessor systems, interface to servo, programmable interface controller characterised by using several processors for different functions, distributed (real-time) systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/004—Artificial life, i.e. computing arrangements simulating life
    • G06N3/008—Artificial life, i.e. computing arrangements simulating life based on physical entities controlled by simulated intelligence so as to replicate intelligent life forms, e.g. based on robots replicating pets or humans in their appearance or behaviour
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/33—Director till display
    • G05B2219/33212—Processor for communication with, evaluation of signals form detector to pc
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/40—Robotics, robotics mapping to robotics vision
    • G05B2219/40304—Modular structure
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1004—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's to protect a block of data words, e.g. CRC or checksum

Definitions

  • the present invention belongs to the field of control and control systems embedded on robots. More precisely, it applies to the architecture of robots that move on or use articulated members, in particular of human or animal form.
  • a robot can be called a humanoid from the moment it has certain attributes of human appearance: a head, a trunk, two arms, two hands, two legs, two feet ...
  • a humanoid robot can however be more or less evolved. Its members may have a larger or smaller number of joints. He can manage his balance in static and dynamic himself and walk on two members, possibly in three dimensions. It can pick up signals from the environment ("hear", "see”, “touch”, “feel” ...) and react according to more or less sophisticated behaviors, as well as interact with other robots or human beings, either by word or gesture.
  • a control-command architecture comprising a single central computing unit that drives all the joint control motors quickly reaches its limits, particularly because of the heaviness of the associated connectivity.
  • An alternative is to provide a decentralized architecture, classical in industrial robotics systems, with a motherboard and a controller board per motor unit or sensor. In the case of a humanoid robot having the functions indicated, the management of the input / output communications of the motherboard then becomes very heavy for the processor thereof, until it saturates.
  • the present invention solves this problem by providing a control architecture at least three levels, a control level sensors / actuators by an electronic card with at least one microcontroller, a level of translation and transmission of commands to said cards and direct control of basic functions, and a level of generation of higher-level functions involving artificial intelligence of the robot.
  • the present invention discloses a mobile robot on articulated members comprising a plurality of subsets of sensors and actuators, each subassembly being controlled by an electronic card, characterized in that the control functions of at least a portion of the electronic cards are distributed between at least a first computer and a second computer, said first computer ensuring in particular the transmission to said electronic cards of command of execution of functions defined by the second computer.
  • certain functions of the mobile robot are programmed in the first computer, said functions managing the reflexes of the robot by determining commands of the actuators as a function of values of certain state variables of the sensors.
  • certain configuration data of the mobile robot are stored in a memory managed by the first computer, said configuration data including in particular the list of controlled electronic cards, sensors and actuators controlled by said cards and operating parameters of said sensors and actuators.
  • the first computer manages the initialization procedure of at least a portion of the electronic cards of the robot.
  • electronic cards of the robot can be replaced by equivalent cards without modification or the programming of the first computer or the programming of the second computer.
  • the second computer can be replaced by another equivalent computer without modifying the programming of the first computer.
  • the communications between the first computer and the electronic cards are managed by a secure protocol on at least one specific bus, said secure protocol comprising frames comprising before the bytes of the message a byte containing at least the destination address and a bit of significant weight to a chosen value, and after the bytes of the message, at least one byte containing the size of the message and a byte containing a CRC.
  • all the bytes of the frame according to said secure protocol have a first bit at the value complementary to the most significant bit of the address byte and that the first byte every seven octets contains the seven most significant bits of the seven following bytes.
  • said secure protocol comprises a simulcast communication mode.
  • the first computer and the electronic cards that it controls are further connected by at least two communication lines, one of which allows the detection of operation and the other the assignment of addresses to said electronic cards.
  • the present invention also discloses a method of controlling a mobile robot on articulated members comprising a plurality of sensor and actuator subassembly control steps, each subassembly being controlled by an electronic card, characterized in that the steps of controlling at least a part of the electronic cards are distributed between at least a first computer and a second computer, said first computer providing in particular the step of transmitting to said electronic cards of execution control messages functions whose definition step is performed by the second computer.
  • the communications between the first computer and the electronic cards are managed by a secure protocol on at least one specific bus, said secure protocol comprising frames comprising before the bytes of the message a byte containing at least the destination address and a bit most significant at a chosen value, and after the bytes of the message, at least one byte containing the message size and one byte containing a CRC and, in addition, all bytes of the frame according to said secure protocol have a first bit at the value complementary to the most significant bit of the address byte and the first byte every seven bytes contains the seven most significant bit of the following seven octets.
  • the control messages are transmitted to the electronic cards with a substantially fixed period whose order of magnitude is about ten milliseconds.
  • control messages produced by the second computer comprise at least one execution date per command.
  • values of the dated orders are calculated by interpolation on the periodic mailing dates between the values just before and the values just after.
  • the servocontrol instructions executed by an electronic card between a first command and a second command are extrapolated from the preceding commands by extending the command variation speed between the command preceding the first command and said first command.
  • the servocontrol instructions executed by an electronic card between a first command and a second command are extrapolated from the preceding commands by translating the command variation speed between the command preceding the first command and said first command on the servo command. applied between the first and second orders.
  • This architecture has the advantage of releasing most of the power calculation of the unit of the highest level for artificial intelligence tasks that ensure the generation of robot behavior in adequacy with usage profiles of said robot. It also makes it possible to manage the communications between the different computers on different buses, optimized by level, and to provide also optimized communication protocols. In addition, this architecture has the additional advantage that parts of the robot can be changed without reconfiguration of the robot core. It is also optimal for using dated commands that are needed to synchronize the execution of orders transmitted to the many joints of a robot humanoid, possibly from a remote machine or another robot in communication with the first robot via an asynchronous link.
  • FIG. 1 is a diagram of the physical architecture of a humanoid robot in one embodiment of the invention
  • FIG. 2 is a diagram of the functional architecture of a humanoid robot in one embodiment of the invention.
  • FIG. 3 is a block diagram of the logical architecture of a humanoid robot in one embodiment of the invention.
  • FIG. 4 is a diagram illustrating the transmission by the first computer of commands generated by the second computer to the electronic cards in a humanoid robot in one embodiment of the invention
  • FIGS. 5A and 5B are timing diagrams illustrating the generation of commands dated by one of the first or second level computers for transmission to the lower level electronic cards in a humanoid robot in one embodiment of the invention
  • FIGS. 6A, 6B, 6C and 6D are timing diagrams illustrating different merger scenarios of the dated commands in one embodiment of the invention.
  • FIG. 7 illustrates the distribution of the configuration elements between the different levels of the architecture of a humanoid robot in one embodiment of the invention.
  • Figure 1 illustrates the physical architecture of a humanoid robot in one embodiment of the invention.
  • This robot comprises about two dozen electronic cards of the sensor control type 120 and actuators 130 which control the joints.
  • the map 10 shown on the figure is the one that controls the left foot.
  • One of the virtues of architecture is that the cards controlling the joints are for the most part interchangeable.
  • a joint normally has at least two degrees of freedom and therefore two motors. Each motor is driven at an angle.
  • the joint also includes several position sensors, including MRE (Magnetic Rotary Encoder).
  • the control electronic card comprises a commercial microcontroller 110. This may be for example a DSPIC TM from Microchip. It is a 16-bit MCU coupled to a DSP. This MCU has a servo loop cycle of one ms.
  • the robot can also include other types of actuators, including LEDs 140 (electroluminescent diodes) whose color and intensity can reflect the emotions of the robot. It may also include other types of position sensors, including an inertial unit, FSR (ground pressure sensors), etc ....
  • the head comprises the intelligence of the robot, including the card 30 which executes the high-level functions that allow the robot to perform the tasks assigned to it.
  • the card 30 could however be located elsewhere in the robot, for example in the trunk. However, we will see that this location, when the head is removable, can replace these high-level functions and thus in particular to completely change the intelligence of the robot and therefore its missions very quickly. Or conversely to change a body by another (for example a defective body by a non defective) keeping the same artificial intelligence.
  • the head may also include specialized cards, especially in the treatment of speech or vision.
  • the processor 310 of the card 30 may be a commercial x86 processor. A low-power processor such as the Géode TM from AMD (32-bit, 500 MHz) will be favorably selected.
  • the card also includes a set of RAM and flash memories. This card also manages the communication of the robot with the outside (behavior server, other robots ...), normally on a WiFi transmission layer, WiMax " possibly on a public network of mobile data communications with standard protocols possibly encapsulated in a VPN.
  • the processor 310 is normally controlled by a standard OS, which makes it possible to use the usual high-level languages (C, C ++, Python, Ruby, etc.) or the specific languages. articular intelligence as URBI (programming language specialized in robotics) for the programming of high-level functions.
  • URBI programming language specialized in robotics
  • a card 20 is housed in the trunk of the robot. This is where the computer which, according to the invention, ensures the transmission to the cards 10 orders calculated by the card 30. This card could be housed elsewhere in the robot. But the location in the trunk is advantageous because it is located near the head and at the crossroads of the four members, which allows to minimize the connectivity connecting the card 30 to the card 20 and the cards 10.
  • the computer 210 of this card 20 is also a commercial processor. This may advantageously be a 32-bit processor ARM 7 TM type clocked at 60 MHz. The type of processor, its central position, close to the on / off button, its connection to the control of the power supply make it a tool well adapted for the management of the power supply of the robot (standby mode, emergency stop,. ..).
  • the card also includes a set of RAM and flash memories.
  • FIG. 2 illustrates the main function of the computer 210 which is to ensure the transmission of the commands produced by the computer 310 to the cards 10 comprising in particular sensors 120, actuators (for example motors 130 and possibly LEDs 140). Some orders may be transmitted directly to certain cards without passing through the card 20. This is particularly the case for the cards in the head that do not include a motor (cards to control the LEDs of the face, the detection of the touch and LEDs of the ears).
  • the link between these cards and the card 30 is advantageously provided by an I2C bus, effective for the signal frames that borrow it.
  • the card 20 is connected to the card 30 by a USB bus which has a sufficient reliability and speed for this function, and which uses very little power on the processor 30. Moreover, this USB link makes it possible, when removing the In one embodiment, the head containing the card 30 directly connects the other elements of the calculation architecture to an external computer to carry out the developments and the test.
  • a USB protocol adapted for this application is briefly described below.
  • the structure of the message is traditional: a header comprising a first fixed byte, a second type byte, an address byte, a message length byte, the message bytes (up to 128 bytes) and two bytes fixed end of message whose first is identical to the first byte of the header.
  • the bytes of the message that are equal to the first byte of header are systematically doubled to undeceive the receiver.
  • a specificity of the protocol used is the management of positive and negative acknowledgments (ACK and NACK) for reading and writing.
  • ACK positive and negative acknowledgments
  • NACK negative acknowledgments
  • the message includes in the "Data” field those that have been read or written. If the operation fails (NACK), the "Data" field has a specific sequence.
  • the card 20 communicates with the cards 10 located in the upper limbs and the lower limbs by two links for example of the RS485 type.
  • Each RS485 link is completed by a debug line to which all the cards 10 and the card 20 are connected and a member-by-member chaining line which passes from the first card 10 from one member to the next starting from the card 20.
  • the function of these lines is explained later in the description.
  • RS485 links are widely used in industrial environments and are suitable for use in controlling and controlling a humanoid robot because of their very low susceptibility to pests. In addition, they offer a bit rate higher than 46,600 bytes per second, which is necessary to exchange a lot of information in both directions. However, they have the disadvantage that the message frames are sent continuously on the link which makes it more difficult to decode the messages. It is therefore necessary to use a secure communication protocol for finding the different messages in the frames.
  • the message header consists of a byte including the six-bit destination address, a bit indicating whether to read or write, and a most significant bit always at 1.
  • the beginning message contains two bytes in addition to the address, the first coding the size of the message, the second the type of the message and the last byte of the message is constituted by a CRC covering the entire message.
  • the messages can be of the type: joint angle, viscosity of a joint, reset, LEDs, device configuration, various reprogramming commands, etc.
  • the 1 st destination address is set to zero.
  • the destination cards of a part of the message are identified by a BID or Broadcast ID which allows each card to find the part of the message intended for it.
  • This mode makes it possible in particular to send commands to the actuators, such as the positions of the joints to be reached.
  • the protocol is slightly different: the master sends the 1st byte (always with the MSB at 1) followed by the number of bytes to be requested on 7 bits and a CRC on 7 bits of these two bytes.
  • the card designated by the address only responds if the CRC is good. It then responds to the number of bytes requested with the MSB always at 0.
  • the data read on the motor cards depends on the requested length, the starting point being always the same. The most useful and most frequently read data is placed at the beginning of the area to be read. These are the positions of the joint sensors, current, errors and temperature.
  • At the level of the torso card 20 there is no count of bytes. There is only a time-out corresponding to the time of sending the response bytes with a margin. At the end of the time-out, the card has received or not the bytes, which makes it possible not to disturb the operation of the rest of the robot in case of failure of a card.
  • the debugging and chaining links are used essentially at the time of initialization of the robot, the management of which is also ensured by the card 20, which is another of its important functions.
  • the map 20 is controlled by the ignition button and initializes first.
  • the cards 10 and the card 30 then start; your cards 10 send on the debug line a bit at 0; the card 20 sends back to them a command on the chaining line which passes this status bit to 1.
  • the addresses are then allocated in increments of one unit by one for each of the cards on each line of chaining, until the last card of the member. It is therefore the position of the cards 10 in the chain that creates a "physical" differentiation between them while they are identical. In case of reset, the entire chaining is replayed.
  • the debugging and chaining lines are, for example, lines using the One Wire protocol on which square pulse trains which code bits 0 (duration of the pulse in the low state of the order of 50 ⁇ s) circulate. and 1 (duration of the pulse in the low state of the order of 250 ⁇ s).
  • FIG. 3 illustrates the logical architecture of a humanoid robot according to the invention.
  • the robot comprises a card management module (DCM) which can be implanted essentially on the card 30 but also at least partially on the card 20.
  • the program DCM begins by reading an internal configuration buffer to each card 10 (for example a motor card). At this stage, this buffer only contains internal indications to the card (versions of the bootloader - automatic loader of the boot file, the program, the card, address of the card obtained by the chaining).
  • the buffer is filled in the DCM by all the configuration values: BID, number and position of the MRE in the chain, number and position of the motors, joint servo coefficient, presence of LEDs, or FSR, etc.
  • the buffer is then sent again to the card 10, This update of the configuration parameters of the cards 10 advantageously replaces an update of the flash memory of the cards.
  • the data read on the cards 10 are stored in an internal robot database (STM) kept in RAM.
  • STM internal robot database
  • the logic architecture of the robot is broken down into a type of master device referred to as Devices in the following description (essentially MCU 110 of the electronics boards 10 of the robot) then to slave devices called SubDevices (sensors 120 or actuators 130, 140) connected to the Device.
  • Devices are themselves same slaves compared to the whole cards 20,30. They are characterized by a type, a bus (I2C head or torso, RS485 up or down) and an address on this bus.
  • the SubDevices are characterized by a type (motors, LEDs FSR ...) that define whether they are sensor or actuator, the Device attached and the number of SubDevice.
  • the position of the articulation corresponds to a sensor SubDevice (corresponding to the angular information returned by the sensor) and to an actuator SubDevice separated from the first one, corresponding to the position to be achieved.
  • a motor card preferably includes two motor SubDevices (actuator), 2 SubDevices sensor position (sensor), 2 current SubDevices (sensor) ...
  • the face card can have a large number of LED SubDevices (actuator) (48). in one embodiment).
  • a SubDevice is also characterized by the floating point value of its main state variable (the angular position of the joint for a position sensor, the current measurement for the current sensor, the value of the LED for the LED actuator, etc.
  • variables derived from the main variable gain, offset, minimum and maximum values, acknowledgment of receipt (ACK) or acknowledgment of non-receipt (NACK), ERROR - different from 0 in case of Devices have no main state variable value, but they have ACK / NACK / ERROR type counter values, and other values are specific to Device or SubDevice types (for example servo coefficients on the motor actuators) All these values are updated automatically and visible in the STM from high-level applications.
  • variables derived from the main variable gain, offset, minimum and maximum values, acknowledgment of receipt (ACK) or acknowledgment of non-receipt (NACK), ERROR - different from 0 in case of Devices have no main state variable value, but they have ACK / NACK / ERROR type counter values, and other values are specific to Device or SubDevice types (for example servo coefficients on the motor actuators) All these values are updated automatically and visible in the STM from high-level applications.
  • the ACK and NACK counters are respectively incremented for each successful communication or for each communication error with the Device / SubDevice. They can detect card access problems and calculate their frequency.
  • This Device / SubDevice architecture is described for each robot in a configuration file present by default (standard configuration) in the card 30 and easily modifiable, but certain specific values are also stored in a flash memory of the card 20. This is of another important function of this card 20 which thus preserves the independence between the high level and the low level of the robot.
  • the DCM does not itself have information "hard” on the electronic architecture of the robot. Access to the sensors and actuators is via a "key" bearing the name of SubDevice / Value.
  • the DCM operates with an internal cycle of 10 to 20ms. Most sensors and actuators are updated / read systematically at each cycle. This makes it possible to operate at constant load, to optimize communications, to make a communication error non-critical (it only lasts 20ms).
  • the card 20 converts commands developed by the DCM and transmitted in a USB protocol RS485 protocol. It is also possible to use one of the memories of the card 20 as a buffer of these commands, so as to perform interpolation calculations between commands as indicated below.
  • FIG. 4 illustrates the generation and transmission of a set of commands for the robot to advance by a distance ⁇ by following a heading ⁇ at a speed ⁇ .
  • the processor 30 develops the commands to be applied to the motors of the joints Ai , A 2 , A 3 of the robot to execute the order ⁇ , ⁇ ', ⁇ .
  • the absolute date of the execution is calculated.
  • neither communications between robot cards nor communications from the outside that can provide input parameters to the setpoint to be executed can have a time Guaranteed route to the place of their execution and thus some dates of arrival and execution.
  • the dating of the orders makes it possible to ensure their synchronization in this context in a relatively simple way. For example, the system date of the processor 30 can be used.
  • the DCM Depending on the configuration information and the state of the known system, the DCM generates a series of values of the variable ⁇ (angle control) of the stress of the actuators A, a sequence of moments t in the future, ⁇ o ⁇ t ⁇ .
  • the duration T on which it is possible to calculate and transmit the values ⁇ is a function notably of the memory capacity of the dedicated RAM of the DCM. Insofar as the DCM has its own cycle (10 to 20 ms as already indicated), it is necessary to generate current commands at the moment the frames are transmitted.
  • the processor 210 For sending new commands, it is also possible to merge two suites ⁇ t ⁇ concerning the same actuator, the one in DCM RAM and a new one sent by an external module. This operation is performed before the interpolation. The result of the interpolation is encapsulated in USB frames and then transmitted from the card 30 to the card 20. In a variant, it is also possible to transmit the sequence ⁇ ) it ⁇ and to carry out the transformations in the card 20. In both cases, the processor 210 then carries out the elimination of the USB protocol and the encapsulation in RS485 frames according to the secure protocol described above.
  • the simulcast mode is privileged, by coding the addresses of the Devices containing the SubDevices A, to execute the commands.
  • the frames are then transmitted simultaneously on the RS485 bus to the Devices controlling the SubDevices A, to execute commands.
  • the frame control procedure makes it possible to ensure the integrity of the transmitted messages.
  • An interpolation is carried out on the 1 st Devices between the command to be executed and the last previously executed in order to smooth movements of the joints. Transformations by linear interpolation performed on transmission are illustrated by FIGS. 5A and 5B.
  • 7 commands spaced by 10 ms replace one another with two commands spaced apart by 70 ms.
  • the values of the orders evolve without difficulty in a monotonous way.
  • FIG. 5B where there is a change of direction of variation of the state variable, the stair interpolation function makes it possible to reconstruct this change more smoothly.
  • FIGS. 6A, 6B, 6C and 6D Various types of command frame merging transformations are illustrated in FIGS. 6A, 6B, 6C and 6D.
  • the merger consists of taking into account all the commands.
  • the oldest command is erased beyond a given date.
  • the oldest command is erased before a given date.
  • the oldest command is completely cleared.
  • FIG. 7B illustrates this second type of significant deceleration situation and applies to it another method of calculating the evolution of the setpoint, which consists of introducing a delay effect of one cycle: ⁇ 2 is the translated of ⁇ 2 of a cycle. We can see graphically that thus ⁇ 2 is closer to ⁇ 2 than would result from the previous calculation.
  • the plug-ins can retrieve the system clock in a simple way, and thus synchronize with the command generator. To reduce the calculation load of the DCM, it is possible to group the commands to be addressed to several actuators on an alias.
  • Device.xml configuration file (preference) and several subfiles linked to some parts of the robot (Device_Head.xml, Device_Chest.xml and others if necessary). Some parts of the robot are interchangeable. The head can be easily separated from the body or implanted again. Arms or other parts of the robot can also be replaced. This versatility is both useful for maintenance and, as already indicated, to adapt a robot to new missions or give it a new personality or a new appearance. But there are calibration values associated with these parts that are essential to take into account the specific implementation (calibration of joint sensors, LEDs, modifications made to adjust certain parameters after mounting ).

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • General Physics & Mathematics (AREA)
  • Artificial Intelligence (AREA)
  • Evolutionary Computation (AREA)
  • Theoretical Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Robotics (AREA)
  • Human Computer Interaction (AREA)
  • Manufacturing & Machinery (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Mechanical Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Biomedical Technology (AREA)
  • Fuzzy Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Biophysics (AREA)
  • General Health & Medical Sciences (AREA)
  • Molecular Biology (AREA)
  • Computing Systems (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Hardware Design (AREA)
  • Manipulator (AREA)

Abstract

La présente invention s'applique à un robot mobile qui peut avoir apparence humaine et des fonctions élaborées lui permettant d'exécuter des missions. Pour permettre une optimisation des communications internes au robot et une versatilité à la fois physique (substitution possible de parties du robot) et logicielle (remplacement de programmes pour l'adapter à de nouvelles missions), une architecture à trois niveaux de calculateurs est prévue. Le niveau le plus haut comprend l'intelligence du robot qui élabore des commandes qui sont transmises par un calculateur intermédiaire à des cartes de bas niveau qui contrôle les capteurs et actionneurs. La communication entre le calculateur intermédiaire et les cartes de bas niveau est gérée par au moins un protocole de communication sécurisé spécifique.

Description

ARCHITECTURE DE CONTROLE - COMMANDE D'UN ROBOT MOBILE UTILISANT DES MEMBRES ARTICULES
La présente invention appartient au domaine des systèmes de contrôle et de commande embarqués sur des robots. Plus précisément, elle s'applique à l'architecture de robots qui se déplacent sur ou utilisent des membres articulés, notamment de forme humaine ou animale. Un robot peut être qualifié d'humanoïde à partir du moment où il possède certains attributs de l'apparence humaine : une tête, un tronc, deux bras, deux mains, deux jambes, deux pieds... Un robot humanoïde peut cependant être plus ou moins évolué. Ses membres peuvent avoir un nombre plus ou moins importants d'articulations. Il peut gérer lui-même son équilibre en statique et en dynamique et marcher sur deux membres, éventuellement en trois dimensions. Il peut capter des signaux de l'environnement (« entendre », « voir », « toucher », « sentir »...) et réagir selon des comportements plus ou moins sophistiqués, ainsi qu'interagir avec d'autres robots ou des humains, soit par la parole soit par le geste. Plus on souhaitera donner au robot une apparence et un comportement humains, plus il sera nécessaire de donner de degrés de liberté sous contrainte aux articulations des membres (donc de multiplier les moteurs pilotant ces articulations), de multiplier les capteurs, et les traitements et de générer des réactions réflexes. Plus on souhaitera l'adapter à des missions définies par des utilisateurs (humains, eux), plus il sera nécessaire de prévoir la possibilité de personnaliser la structure physique du robot (en remplaçant par exemple une tête par une autre) et son intelligence (en mettant à jour les programmes qui la constituent, ce qui peut nécessiter des interactions avec un serveur d'où il pourra télécharger les applications nouvelles faisant évoluer ses missions ou ses comportements). Cette complexification et cette versatilité des structures physiques et logicielles de robots mobiles sur des membres articulés ne peut pas être réalisée dans les architectures de l'art antérieur. En effet, une architecture de contrôle-commande comportant une seule unité centrale de calcul qui pilote tous les moteurs de commande des articulations atteint rapidement ses limites, notamment en raison de la lourdeur de la connectique associée. Une alternative est de prévoir une architecture décentralisée, classique dans des systèmes de robotique industrielle, avec une carte mère et une carte contrôleur par unité moteur ou capteur. Dans le cas d'un robot humanoïde ayant les fonctions indiquées, la gestion des communications en entrée/sortie de la carte mère devient alors très lourde pour le processeur de celle-ci, jusqu'à la saturer. La présente invention résout ce problème en prévoyant une architecture de contrôle-commande à au moins trois niveaux, un niveau de commande des capteurs/actionneurs par une carte électronique dotée d'au moins un microcontrôleur, un niveau de traduction et transmission de commandes aux dites cartes et de pilotage direct de fonctions de base, et un niveau de génération de fonctions de plus haut niveau comportant l'intelligence artificielle du robot.
A cet effet, la présente invention divulgue un robot mobile sur des membres articulés comprenant une pluralité de sous-ensembles de capteurs et d'actionneurs, chaque sous-ensemble étant commandé par une carte électronique, caractérisé en ce que les fonctions de contrôle d'au moins une partie des cartes électroniques sont réparties entre au moins un premier calculateur et un deuxième calculateur, ledit premier calculateur assurant notamment la transmission aux dites cartes électroniques de messages de commande d'exécution de fonctions définies par le deuxième calculateur. Avantageusement, certaines fonctions du robot mobile sont programmées dans le premier calculateur, les dites fonctions gérant les réflexes du robot en déterminant des commandes des actionneurs en fonction de valeurs de certaines variables d'état des capteurs. Avantageusement, certaines données de configuration du robot mobile sont stockées dans une mémoire gérée par le premier calculateur, les dites données de configuration comprenant notamment la liste des cartes électroniques contrôlées, les capteurs et actionneurs commandés par les dites cartes et des paramètres de fonctionnement des dits capteurs et actionneurs. Avantageusement, le premier calculateur gère la procédure d'initialisation d'au moins une partie des cartes électroniques du robot. Avantageusement, des cartes électroniques du robot peuvent être remplacées par des cartes équivalentes sans modification ni de la programmation du premier calculateur ni de la programmation du deuxième calculateur. Avantageusement, le deuxième calculateur peut être remplacé par un autre calculateur équivalent sans modification de la programmation du premier calculateur.
Avantageusement, les communications entre le premier calculateur et les cartes électroniques sont gérées par un protocole sécurisé sur au moins un bus spécifique, ledit protocole sécurisé comportant des trames comprenant avant les octets du message un octet contenant au moins l'adresse de destination et un bit de poids fort à une valeur choisie, et après les octets du message, au moins un octet contenant la taille du message et un octet contenant un CRC.
Avantageusement, tous les octets de la trame selon ledit protocole sécurisé ont un premier bit à la valeur complémentaire du bit de poids fort de l'octet d'adresse et que le premier octet tous les sept octets contient les sept bit des poids fort des sept octets suivants. Avantageusement, ledit protocole sécurisé comporte un mode de communication simulcast.
Avantageusement, le premier calculateur et les cartes électroniques qu'il contrôle sont en outre connectés par au moins deux lignes de communication dont l'une permet la détection de fonctionnement et l'autre l'attribution d'adresses aux dites cartes électroniques.
La présente invention divulgue également un procédé de contrôle d'un robot mobile sur des membres articulés comprenant une pluralité de d'étapes de commandes de sous-ensembles de capteurs et d'actionneurs, chaque sous- ensemble étant commandé par une carte électronique, caractérisé en ce que les étapes de contrôle d'au moins une partie des cartes électroniques sont réparties entre au moins un premier calculateur et un deuxième calculateur, ledit premier calculateur assurant notamment l'étape de transmission aux dites cartes électroniques de messages de commande d'exécution de fonctions dont l'étape de définition est réalisée par le deuxième calculateur. Avantageusement, les communications entre le premier calculateur et les cartes électroniques sont gérées par un protocole sécurisé sur au moins un bus spécifique, ledit protocole sécurisé comportant des trames comprenant avant les octets du message un octet contenant au moins l'adresse de destination et un bit de poids fort à une valeur choisie, et après les octets du message, au moins un octet contenant la taille du message et un octet contenant un CRC et, en en outre, tous les octets de la trame selon ledit protocole sécurisé ont un premier bit à la valeur complémentaire du bit de poids fort de l'octet d'adresse et le premier octet tous les sept octets contient les sept bit des poids fort des sept octets suivants. Avantageusement, les messages de commande sont transmis aux cartes électroniques avec une période sensiblement fixe dont l'ordre de grandeur est Ia dizaine de millisecondes.
Avantageusement, les messages de commande élaborés par le deuxième calculateur comportent au moins une date d'exécution par commande. Avantageusement, les valeurs des commandes datées sont calculées par interpolation aux dates d'envoi périodiques entre les valeurs juste avant et les valeurs juste après.
Avantageusement, les consignes d'asservissement exécutées par une carte électronique entre une première commande et une deuxième commande sont extrapolées des commandes précédentes en prolongeant la vitesse de variation de commande entre la commande précédent la première commande et ladite première commande.
Avantageusement, les consignes d'asservissement exécutées par une carte électronique entre une première commande et une deuxième commande sont extrapolées des commandes précédentes en translatant la vitesse de variation de commande entre la commande précédent la première commande et ladite première commande sur la consigne d'asservissement appliquée entre la première et Ia deuxième commandes.
Cette architecture présente l'avantage de libérer l'essentiel de la puissance ce calcul de l'unité de plus haut niveau pour les tâches d'intelligence artificielle qui assurent la génération de comportements du robot en adéquation avec des profils d'utilisation dudit robot. Elle permet également de gérer les communications entre les différents calculateurs sur des bus différents, optimisés par niveau, et de prévoir des protocoles de communication également optimisés. En outre, cette architecture présente l'avantage supplémentaire que des parties du robot peuvent être changées sans reconfiguratîon du cœur du robot. Elle est également optimale pour l'utilisation de commandes datées qui sont nécessaires pour synchroniser l'exécution des ordres transmis aux nombreuses articulations d'un robot humanoïde, éventuellement en provenance d'une machine distante ou d'un autre robot en communication avec le premier robot via une liaison asynchrone.
L'invention sera mieux comprise et ses différentes caractéristiques et avantages ressortiront de la description qui suit de plusieurs exemples de réalisation et de ses figures annexées dont :
- La figure 1 est un schéma de l'architecture physique d'un robot humanoïde dans un mode de réalisation de l'invention ;
- La figure 2 est un schéma de l'architecture fonctionnelle d'un robot humanoïde dans un mode de réalisation de l'invention ;
- La figure 3 est un schéma de principe de l'architecture logique d'un robot humanoïde dans un mode de réalisation de l'invention ;
- La figure 4 est un schéma illustrant la transmission par le premier calculateur de commandes générées par le deuxième calculateur aux cartes électroniques dans un robot humanoïde dans un mode de réalisation de l'invention ;
- Les figures 5A et 5B sont des chronogrammes illustrant la génération de commandes datées par l'un des calculateurs de premier ou de deuxième niveau pour transmission aux cartes électroniques de plus bas niveau dans un robot humanoïde dans un mode de réalisation de l'invention ;
- Les figures 6A, 6B, 6C et 6D sont des chronogrammes illustrant différents scénarios de fusion des commandes datées dans un mode de réalisation de l'invention ; - La figure 7 illustre la répartition des éléments de configuration entre les différents niveaux de l'architecture d'un robot humanoïde dans un mode de réalisation de l'invention.
Dans la suite de la description, les abréviations et acronymes ont les significations indiquées dans le tableau ci-dessous, à moins qu'une signification différente ne leur soit explicitement donnée dans un contexte particulier :
Figure imgf000008_0001
La figure 1 illustre l'architecture physique d'un robot humanoïde dans un mode de réalisation de l'invention. Ce robot comprend environ deux douzaines de cartes électroniques du type 10 de commande de capteurs 120 et d'actionneurs 130 qui pilotent les articulations. La carte 10 montrée sur la figure est celle qui contrôle le pied gauche. Une des vertus de l'architecture est que les cartes contrôlant les articulations sont pour la plupart interchangeables. Une articulation a normalement au moins deux degrés de liberté et donc deux moteurs. Chaque moteur est piloté en angle. L'articulation comporte également plusieurs capteurs de position, notamment des MRE (Magnetic Rotary Encoder). La carte électronique de contrôle comporte un microcontrôleur du commerce 110. Ce peut être par exemple un DSPIC™ de la société Microchip. C'est un MCU 16 bits couplé à un DSP. Ce MCU a un cycle d'asservissement en boucle d'une ms. Le robot peut également comporter d'autres types d'actionneurs, notamment des LED 140 (Diodes électroluminescentes) dont la couleur et l'intensité peuvent traduire les émotions du robot. Celui-ci peut également comporter d'autres types de capteurs de position, notamment une centrale inertielle, des FSR (Capteurs de pression au sol), etc.... La tête comporte l'intelligence du robot, notamment la carte 30 qui exécute les fonctions de haut niveau qui permettent au robot d'accomplir les missions qui lui sont assignées. La carte 30 pourrait cependant être située ailleurs dans le robot, par exemple dans le tronc. On verra cependant que cette localisation, lorsque la tête est amovible, permet de remplacer ces fonctions de haut niveau et donc notamment de changer complètement l'intelligence du robot et donc ses missions très rapidement. Ou à l'inverse de changer un corps par un autre (par exemple un corps défectueux par un non défectueux) en gardant la même intelligence artificielle. La tête peut comporter également des cartes spécialisées, notamment dans le traitement de la parole ou de la vision. Le processeur 310 de la carte 30 peut être un processeur x86 du commerce. On choisira de manière privilégiée un processeur à basse consommation tel que le Géode™ de la société AMD (32 bits, 500 MHz). La carte comporte également un ensemble de mémoires RAM et flash. Cette carte gère également les communications du robot avec l'extérieur (serveur de comportements, autres robots...), normalement sur une couche de transmission WiFi, WiMax» éventuellement sur une réseau public de communications mobiles de données avec des protocoles standards éventuellement encapsulés dans un VPN. Le processeur 310 est normalement piloté par un OS standard ce qui permet d'utiliser les langages de haut niveau usuels (C, C++, Python, Ruby,...) ou les langages spécifiques de l'intelligence articifîelle comme URBI (language de programation spécialisé dans la robotique) pour la programmation des fonctions de haut niveau.
Une carte 20 est logée dans le tronc du robot. C'est là que se situe le calculateur qui, selon l'invention, assure la transmission aux cartes 10 des ordres calculés par la carte 30. Cette carte pourrait être logée ailleurs dans le robot. Mais la localisation dans le tronc est avantageuses car elle se situe près de la tête et au carrefour des quatre membres, ce qui permet donc de minimiser la connectique reliant cette carte 30 à la carte 20 et aux cartes 10. Le calculateur 210 de cette carte 20 est également un processeur du commerce. Ce peut avantageusement être un processeur 32 bits du type ARM 7™ cadencé à 60 MHz. Le type du processeur, sa position centrale, proche du bouton de marche/arrêt, sa liaison au contrôle de l'alimentation en font un outil bien adapté pour la gestion de l'alimentation du robot (mode veille, arrêt d'urgence, ...). La carte comporte également un ensemble de mémoires RAM et flash.
Dans cette architecture à trois niveaux selon l'invention, une fonction de reprogrammation des microcontrôleurs 110 et 210 est prévue dans la carte- mère. La figure 2 illustre la fonction principale du calculateur 210 qui est d'assurer la transmission des ordres élaborés par le calculateur 310 aux cartes 10 comprenant notamment des capteurs 120, des actionneurs (par exemple des moteurs 130 et éventuellement des LED 140). Certains ordres peuvent être transmis directement à certaines cartes sans passer par la carte 20. C'est notamment le cas pour les cartes situées dans la tête qui ne comportent pas de moteur (cartes assurant le contrôle des LEDs du visage, de la détection du toucher et des LED des oreilles). La liaison entre ces cartes et la carte 30 est assurée avantageusement par un bus I2C, efficace pour les trames de signaux qui l'empruntent. La carte 20 est reliée à la carte 30 par un bus USB qui a une fiabilité et une vitesse suffisantes pour cette fonction, et qui utilise très peu de puissance sur le processeur 30. En outre, cette liaison USB permet, lorsqu'on enlève la tête contenant Ia carte 30 dans un mode de réalisation, de connecter directement les autres éléments de l'architecture de calcul à un ordinateur externe pour réaliser les développements et le test.. Un protocole USB adapté pour cette application est décrit sommairement ci- après. La structure du message est classique : un en-tête comprenant un premier octet fixe, un deuxième octet de type, un octet d'adresse, un octet de longueur de message, les octets du message (jusqu'à 128 octets) et deux octets fixes de fin de message dont le premier est identique au premier octet d'en-tête. Les octets du message qui sont égaux au premier octet d'en- tête sont systématiquement doublés pour détromper le récepteur. Une spécificité du protocole utilisé est la gestion des accusés de réception positifs et négatifs (ACK et NACK) à la lecture et à l'écriture. Dans les deux cas, si l'opération est réussie (ACK), le message comprend dans le champ « Données » celles qui ont été lues ou écrites. Si l'opération échoue (NACK), le champ « Données » comporte une séquence spécifique. La carte 20 communique avec les cartes 10 situées dans les membres supérieurs et les membres inférieurs par deux liaisons par exemple du type RS485. Chaque liaison RS485 est complétée par une ligne de débogage à laquelle sont reliées toutes les cartes 10 et la carte 20 et une ligne de chaînage par membre qui passe de la première carte 10 d'un membre à la suivante en partant de la carte 20. La fonction de ces lignes est expliquée plus loin dans la description. Les liaisons RS485 sont très utilisées en environnement industriel et sont adaptées à une utilisation pour la commande et le contrôle d'un robot humanoïde en raison de leur très faible sensibilité aux parasites. En outre elles offrent un débit supérieur à 46.600 octets par seconde qui est nécessaire pour échanger des informations nombreuses dans les deux directions. Elles présentent cependant l'inconvénient que les trames de messages sont envoyées en continu sur la liaison ce qui rend plus difficile le décodage des messages. Il est donc nécessaire d'utiliser un protocole de communication sécurisé permettant de retrouver les différents messages dans les trames. Un des protocoles possibles est décrit ci-après. Il consiste à titre principal à mettre à zéro le premier bit de chaque octet et à insérer avant sept octets un octet comprenant les bits de poids fort des sept octets suivants. Par ailleurs, l'en-tête de message est constitué par un octet comprenant l'adresse de destination sur six bits, un bit qui indique si on fait une lecture ou une écriture, et un bit de poids fort systématiquement à 1. Le début du message comprend deux octets en plus de l'adresse, le premier codant Ia taille du message, le second le type du message et le dernier octet du message est constitué par un CRC portant sur l'intégralité du message. Les messages peuvent être du type : angle d'une articulation, viscosité d'une articulation, réinitialisation, LEDs, configuration d'un Device, diverses commandes de reprogrammation, etc. Pour qu'un message soit valide, il faut donc respecter les critères suivants : 1er MSB à 1 , les autres à 0, adresse, type de message, taille et CRC corrects. La charge de gestion du protocole est assez légère à la fois à l'émission et à la réception. Le message est de taille fixe, ce qui facilite grandement la gestion temporelle de la communication.
Pour alléger la charge liée aux codes de contrôle, il est fait un usage assez large d'une fonction de broadcast, en réalité le plus souvent de simulcast ou émission simultanée à des adresses différentes. Dans ce cas, la 1ere adresse de destination est mise à zéro. Les cartes de destination d'une partie du message sont identifiées par un BID ou Broadcast ID qui permet à chaque carte de retrouver la partie du message qui lui est destiné. Ce mode permet en particulier l'envoi de commandes aux actionneurs, telles que les positions des articulations à atteindre. Pour la lecture des cartes moteurs, le protocole est légèrement différent : le maître envoie le 1er octet (toujours avec le MSB à 1 ) suivi du nombre d'octets à demander sur 7 bits et d'un CRC sur 7 bits de ces deux octets. La carte désignée par l'adresse ne répond que si le CRC est bon. Elle répond alors le nombre d'octets demandé avec le MSB toujours à 0. Les données lues sur les cartes moteurs dépendent de la longueur demandée, le point de départ étant toujours le même. Les données les plus utiles et les plus fréquemment lues sont placées au début de la zone à lire. Il s'agit des positions des capteurs des articulations, du courant, des erreurs et de la température. Au niveau de la carte torse 20 il n'y a pas de comptage des octets. Il y seulement un time-out correspondant au temps d'envoi des octets de réponse avec une marge. A l'issue du time-out, la carte a reçu ou non les octets, ce qui permet de ne pas perturber le fonctionnement du reste du robot en cas de défaillance d'une carte.
Les liaisons de débogage et de chaînage sont utilisées essentiellement au moment de l'initialisation du robot, dont la gestion est également assurée par la carte 20, ce qui est une autre de ses fonctions importantes. La carte 20 est commandée par Ie bouton d'allumage et s'initialise en premier. Les cartes 10 et la carte 30 démarrent ensuite ; tes cartes 10 envoient sur la ligne de débogage un bit à 0 ; la carte 20 leur envoie en retour une commande sur la ligne de chaînage qui fait passer ce bit d'état à 1. Les adresses sont ensuite attribuées par incrément d'une unité de proche en proche pour chacune des cartes sur chaque ligne de chaînage, jusqu'à la dernière carte du membre. C'est donc la position des cartes 10 dans la chaîne qui crée une différentiation « physique » entre celles-ci alors qu'elles sont identiques, En cas de reset, la totalité du chaînage est rejouée. Les lignes de débogage et de chaînage sont par exemple des lignes utilisant le protocole One Wire sur lesquelles circulent des trains d'impulsions carrées qui codent des bits 0 (durée de l'impulsion à l'état bas de l'ordre de 50 μs) et 1 (durée de l'impulsion à l'état bas de l'ordre de 250 μs).
La figure 3 illustre l'architecture logique d'un robot humanoïde selon l'invention.
Le robot comprend un module de gestion des cartes (DCM) qui peut être implanté pour l'essentiel sur la carte 30 mais également au moins partiellement sur la carte 20. Le programme DCM commence par lire un buffer de configuration interne à chaque carte 10 (par exemple une carte moteur). Ce buffer ne comporte à ce stade que des indications internes à la carte (versions du bootloader - chargeur automatique du fichier de démarrage, du programme, de la carte ; adresse de la carte obtenue par le chaînage). Le buffer est complété dans le DCM par toutes les valeurs de configuration : BID, nombre et position des MRE dans la chaîne, nombre et position des moteurs, coefficient d'asservissement des articulations, présence de LED, ou de FSR, etc. Le buffer est ensuite envoyé à nouveau à la carte 10, Cette mise à jour des paramètres de configuration des cartes 10 remplace avantageusement une mise à jour de la mémoire flash des cartes. Les données lues sur les cartes 10 sont stockées dans une base de données interne du robot (STM) conservée en RAM. L'architecture logique du robot se décompose en un type de périphériques maîtres dénommés Devices dans la suite de la description (essentiellement MCU 110 des cartes électroniques 10 du robot) puis en périphériques esclaves dénommés SubDevices (capteurs 120 ou actionneurs 130, 140) reliés au Device. Les Devices sont eux- mêmes esclaves par rapport à l'ensemble cartes 20,30. Hs sont caractérisés par un type, un bus (I2C tête ou torse, RS485 haut ou bas) et une adresse sur ce bus. Les SubDevices sont caractérisés par un type (moteurs, LEDs FSR ...) qui définissent s'ils sont capteur ou actionneur, le Device de rattachement et le numéro de SubDevice.
Il est a noter que la position de l'articulation correspond à un SubDevice capteur (correspondant à l'information angulaire renvoyée par le capteur) et à un SubDevice actionneur séparé du premier, correspondant à la position à atteindre demandée. Par exemple une carte moteur comprend de manière privilégiée deux SubDevices moteur (actionneur), 2 SubDevices position du capteur (capteur), 2 SubDevices courant (capteur)... La carte visage peut comporter un grand nombre de SubDevices LED (actionneur) (48 dans une mode de réalisation). Un SubDevice est également caractérisé par la valeur en virgule flottante de sa variable d'état principale (la position angulaire de l'articulation pour un capteur de position, la mesure de courant pour le capteur de courant, la valeur de la LED pour l'actionneur LED, etc. ainsi que par les valeurs de variables dérivées de la variable principale (gain, offset, valeurs minimale et maximale, accusé de réception (ACK) ou accusé de non réception (NACK), ERREUR - différente de 0 en cas de problème). Les Devices n'ont pas de valeur de variable d'état principale, mais ils ont des valeurs de compteurs du type ACK/NACK/ERREUR. D'autres valeurs sont spécifiques aux types de Devices ou de SubDevices (par exemple les coefficients d'asservissement sur les actuateurs moteur). Toutes ces valeurs sont mises à jour automatiquement et visibles dans la STM depuis les applications du haut niveau.
Les compteurs ACK et NACK s'incrément respectivement à chaque communication réussie ou à chaque erreur de communication avec le Device/SubDevice. Ils permettent de détecter les problèmes d'accès à la carte et de calculer leur fréquence.
Cette architecture Device/SubDevice est décrite pour chaque robot dans un fichier de configuration présent par défaut (configuration standard) dans la carte 30 et facilement modifiable, mais certaines valeurs spécifiques sont aussi stockées dans une mémoire flash de la carte 20. Il s'agit d'une autre fonction importante de cette carte 20 qui permet ainsi de préserver l'indépendance entre le haut niveau et le bas niveau du robot. Le DCM n'a pas lui-même d'information « en dur » sur l'architecture électronique du robot. L'accès aux capteurs et actionneurs se fait par une « clef » portant le nom du SubDevice/Value. Pour le niveau haut, il n'y a aucune différence entre les LEDs des pieds (gérées en RS485 sur une carte moteur via l'USB de la carte torse), les LEDs du torse (gérées par la carte torse via des requêtes USB) , les LEDs du visage (gérées par la carte visage via des requêtes I2C). Dans un mode de réalisation privilégié, le DCM fonctionne avec un cycle interne de 10 à 20ms. La plupart des capteurs et des actionneurs, sont mis à jour/ lus systématiquement à chaque cycle. Cela permet de fonctionner à charge constante, d'optimiser les communications, de rendre non critique une erreur de communication (elle ne « dure » que 20ms). En outre, en préférant une mise à jour systématique de la plupart des capteurs à une mise à jour par une requête, on assure une disponibilité immédiate de l'information à jour pour l'ensemble des modules haut niveau du robot. La carte 20 assure la conversion des commandes élaborées par le DCM et transmises dans un protocole USB en protocole RS485. Il est possible d'utiliser également une des mémoires de la carte 20 comme mémoire tampon de ces commandes, de manière à effectuer des calculs d'interpolation entre commandes comme indiqué plus bas.
A titre d'exemple du fonctionnement de l'architecture selon l'invention, la figure 4 illustre la génération et la transmission d'un ensemble de commandes pour que le robot avance d'une distance δ en suivant un cap θ à une vitesse δ'. Le processeur 30 élabore les commandes à appliquer aux moteurs des articulations Ai, A2, A3 du robot pour exécuter l'ordre δ, δ', θ.
Pour chaque articulation, il y a une ou plusieurs commandes sous la forme d'angles à atteindre. Dans un mode privilégié de réalisation de l'invention, pour toutes les commandes à exécuter on calcule la date absolue de l'exécution. Dans cette architecture de processeurs et de bus non déterministes, ni les communications entre cartes du robot ni les communications en provenance de l'extérieur qui peuvent fournir des paramètres en entrée à la consigne à exécuter, ne peuvent avoir un temps de parcours garanti vers le lieu de leur exécution et donc des dates d'arrivée et d'exécution certaines. La datation des commandes permet d'assurer leur synchronisation dans ce contexte de manière relativement simple. On peut par exemple utiliser la date système du processeur 30. En fonction des informations de configuration et de l'état du système connu, le DCM élabore une suite de valeurs de la variable α (commande en angle) de contrainte des actionneurs A, à une suite d'instants t dans l'avenir, {o^t}. La durée T sur laquelle il est possible de calculer et transmettre les valeurs α est fonction notamment de la capacité mémoire de la RAM dédiée du DCM.. Dans la mesure où le DCM a son propre cycle (10 à 20 ms comme déjà indiqué), il est nécessaire de générer des commandes actuelles au moment où les trames sont transmises. Pour toutes les commandes appliquées à des actionneurs dont les variables d'état sont continues (telles que l'angle qui caractérise la rotation d'un moteur d'articulation ou la luminance d'une LED), cette génération s'opère à l'instant t en recherchant les commandes α,ti et αJt2 qui sont respectivement juste avant t et juste après t., et en réalisant une interpolation linéaire entre ces deux valeurs, pondérées par le temps écoulé entre t1 , t2 et t.
Pour l'envoi de nouvelles commandes, il est également possible de fusionner deux suites {αt} concernant un même actionneur, celle en RAM du DCM et une nouvelle envoyée par un module extérieur. Cette opération est réalisée avant l'interpolation. Le résultat de l'interpolation est encapsulé dans des trames USB puis transmise de la carte 30 à la carte 20. En variante, on peut également transmettre la suite { α)it} et réaliser les transformations dans la carte 20 . Dans les deux cas, le processeur 210 réalise ensuite l'élimination du protocole USB et l'encapsulation dans des trames RS485 selon le protocole sécurisé décrit plus haut. On utilise de manière privilégiée le mode simulcast, en codant les adresses des Devices contenant les SubDevices A, devant exécuter les commandes. Les trames sont ensuite transmises simultanément sur le bus RS485 aux Devices contrôlant les SubDevîces A, devant exécuter des commandes. La procédure de contrôle des trames permet de s'assurer de l'intégrité des messages transmis. Une interpolation est réalisée sur les Devices entre la 1ere commande à exécuter et la dernière exécutée auparavant de manière à lisser les mouvements des articulations. Des transformations par interpolation linéaire opérées à l'émission sont illustrées par les figures 5A et 5B. Dans le cas simple de la figure 5A, 7 commandes espacées de 10 ms se substituent au fur et à mesure à deux commandes espacées de 70 ms. Les valeurs des commandes évoluent sans difficulté de manière monotone. Dans le cas plus complexe de la figure 5B où il y a un changement de sens de variation de la variable d'état, la fonction d'interpolation en escalier permet de reconstituer ce changement de manière plus lissée.
Différents types de transformations par fusion de trames de commandes sont illustrées par les figures 6A, 6B, 6C et 6D. Dans le cas de la figure 6A, la fusion consiste à prendre en compte toutes les commandes. Dans le cas de la figure 6B, la commande la plus ancienne est effacée au-delà d'une date donnée. Dans le cas de la figure 6C, la commande la plus ancienne est effacée avant une date donnée. Dans le cas de la figure 6D, la commande la plus ancienne est complètement effacée.
Il est également avantageux de lisser l'exécution des commandes reçues par un actuateur de manière à éviter, dans la mesure du possible, les discontinuités. Pour ce faire, différents algorithmes d'extrapolation sont possibles. Deux d'entre eux sont illustrés par les figures 7A et 7B. Onrappelle tout d'abord que le cycle de réception des commandes des de l'ordre de la dizaine de ms (20 ms dans un mode de réalisation privilégié actuel) et qu'il est à peu près constant hors sauf contention de charge réseau ou processeur, alors que le cycle d'asservissement est de l'ordre de la ms. Dans le cas de la figure 7A, on considère que la vitesse d'évolution de la commande αt, telle que mesurée sur la période to, ti, (α't, = (an - ato)/( ti - to)) est constante sur l'intervalle de temps suivant ti, t2. L'asservissement sur une consigne extrapolée (Vθ ε [ti, t2], αe = αω + α't, *( θ - tO) permet d'atteindre une commande β2 en ti alors qu'à défaut la consigne d'asservissement passerait brutalement de CH à α2. On voit de manière graphique, si la consigne reste à vitesse constante, accélère ou décélère légèrement, l'asservissement à une consigne interpolée de cette manière est plus efficace que le maintien de la consigne précédente, puisque la différence β2 - α2 est plus petite que la différence α2 - α-i. On note que dans ce cas, l'asservissement effectivement réalisé va de β2 à β3, β3 correspondant à la consigne extrapolée entre (CH , tι) et (02, Î2). Cette condition n'est pas remplie si la consigne décélère très rapidement : dans ce cas la différence β2 - 02 est plus grande que la différence 02 - α-t. L'évolution de la consigne est figurée en traits pleins. Sur la figure 7B, on a illustré ce deuxième type de situation de décélération significative et on lui applique un autre mode de calcul de l'évolution de la consigne qui consiste à introduire un effet retard d'un cycle : γ2 est le translaté de α2 d'un cycle. On voit graphiquement qu'ainsi γ2 est plus proche d' α2 que qui résulterait du calcul précédent. En revanche, au cycle suivant, l'écart s'inverse, mais la somme des deux reste favorable. Il est en outre utile d'introduire un certain nombre de règles de comportement pour régler l'évolution des consignes dans des cas particuliers : si un algorithme d'extrapolation ne peut fonctionner, la consigne est laissée inchangée ; si aucune commande n'est reçue pendant un temps chosi, par exemple, pour un cycle de 20 ms, 50ms, on n'applique pas d'extrapolation en laissant la consigne à la valeur atteinte en dernier ; on bout d'un autre temps choisi, par exemple 10 fois le temps choisi dans le cas précédent, on arrête le robot ; on ne coupe cependant jamais l'actionneur en préférant appliquer une consigne de freinage électromagnétique pour éviter une chute brutale du robot ou d'une de ses articulations.
Les avantages d'un système de commandes datées tel que décrit ci-dessus sont multiples : - il évite par défaut les discontinuités brusques, même si celles-ci restent possibles en cas de besoin avec deux commandes avec des dates très proches;
- il permet en une seule commande de faire une interpolation linéaire entre deux valeurs qui est une interpolation simple mais toujours valable (on peut ramener les autres interpolations en une suite d'interpolations linéaires, et donc minimiser aussi les commandes dans des cas plus complexes) ;
- il permet d'éviter les problèmes de synchronisation entre le DCM (qui a son propre cycle) et les autres modules ; il suffit par exemple de donner les commandes au moins un cycle à l'avance au DCM pour qu'il calcule une interpolation correspondant à la consigne, ce qui ne génère pas d'à-coup dans les mouvements ; il procure une précision dans les consignes, et donc les mouvements, qui est excellente ; - il est insensible aux éventuels retards, latences, ou délais variables de communications ; il permet de synchroniser très simplement plusieurs actuateurs, même s'ils sont commandés par des modules totalement différents, et situés ou non dans le robot. En outre, les modules externes peuvent récupérer l'horloge système de manière simple, et donc se synchroniser avec le générateur de commandes. Pour diminuer la charge de calcul du DCM, il est possible de regrouper les commandes à adresser à plusieurs actionneurs sur un alias.
On peut également envisager de générer ou modifier des commandes pour les actionneurs directement dans le calculateur 210. En particulier, un certain nombre d'événements ne nécessitent pas forcément l'intervention du calculateur de haut niveau. Certaines fonctions réflexes notamment peuvent être directement pilotées dans la carte 20, notamment la gestion de l'équilibre du robot ou l'évitement de collisions entre membres. Il suffit d'implanter l'algorithmie correspondante et une partie du DCM sur la carte 20.
Pour assurer une certaine versatilité du robot, il est par ailleurs nécessaire de prévoir des fichiers contenant les configurations matérielle et logicielle facilement accessibles et modifiables. La répartition de ces fichiers de configuration est illustrée par la figure 7.
Il y a un fichier de configuration (préférence) Device.xml et plusieurs sous- fïchiers liés à certaines parties du robot (Device_Head.xml, Device_Chest.xml et d'autres si c'est nécessaire). Certaines parties du robot sont interchangeables. La tête peut être facilement séparée du corps ou y être à nouveau implantée. Des bras ou d'autres parties du robot peuvent également être remplacés. Cette versatilité est à la fois utile pour la maintenance et, comme déjà indiqué, pour adapter un robot à de nouvelles missions ou lui donner une nouvelle personnalité ou une nouvelle apparence. Or il y a des valeurs de calibration associés à ces parties qui sont indispensables pour tenir compte de manière fine de l'implantation spécifique (calibration des capteurs des articulations, des LEDs, modifications apportées pour ajuster certains paramètres après montage...) . La meilleure solution n'est donc pas de stocker ces valeurs de calibration dans des fichiers de la carte tête, sous peine d'avoir une mauvaise calibration du corps en cas d'échange de tête. Il est préférable de ne stocker dans un fichier commun à tous les robots (Device.xml) que les valeurs par défaut et sans calibration de la configuration de base complète sous une forme clef = valeur. Les valeurs des clefs de ce fichier sont écrasées par 2 autres fichiers. Le 1er est lié à la tête, et est enregistré comme un fichier séparé (Device_Head.xml). Il contient la calibration de l'ensemble des SubDevices de la tête (LEDs essentiellement). Dans la carte torse est stocké un fichier qui est associé à l'ensemble du corps du robot (Device_Chest.xml). Au lancement, le « chest config in flash » est lu dans la carte torse et copié dans la RAM du DCM ainsi que, sous forme de fichier temporaire, dans le système de fichier Préférences de la tête. Les valeurs du Device.xml dans la STM sont écrasées.
La seule référence est donc le contenu de la mémoire flash de la carte torse. Ainsi en cas d'échange de têtes, le fichier de la carte torse du nouveau corps sera donc lu, éliminant tout problème possible.
Les exemples décrits ci-dessus sont donnés à titre d'illustration de modes de réalisation de l'invention. Ils ne limitent en aucune manière le champ de l'invention qui est défini par les revendications qui suivent.

Claims

REVENDICATIONS
1. Robot mobile sur des membres articulés comprenant une pluralité de sous-ensembles de capteurs et d'actionneurs, chaque sous-ensemble étant commandé par une carte électronique (10), caractérisé en ce que les fonctions de contrôle d'au moins une partie des cartes électroniques sont réparties entre au moins un premier calculateur (20) et un deuxième calculateur (30), ledit premier calculateur (20) assurant notamment la transmission aux dites cartes électroniques (10) de messages de commande d'exécution de fonctions définies par le deuxième calculateur (30).
2. Robot mobile selon la revendication 1 caractérisé en ce que certaines fonctions du robot mobile sont programmées dans le premier calculateur, les dites fonctions gérant les réflexes du robot en déterminant des commandes des actionneurs en fonction de valeurs de certaines variables d'état des capteurs.
3. Robot mobile selon la revendication 1 caractérisé en ce que certaines données de configuration du robot mobile sont stockées dans une mémoire gérée par le premier calculateur, les dites données de configuration comprenant notamment la liste des cartes électroniques contrôlées, les capteurs et actionneurs commandés par les dites cartes et des paramètres de fonctionnement des dits capteurs et actionneurs.
4. Robot mobile selon la revendication 1 caractérisé en ce que le premier calculateur gère la procédure d'initialisation d'au moins une partie des cartes électroniques du robot.
5. Robot mobile selon la revendication 1 caractérisé en ce que des cartes électroniques du robot peuvent être remplacées par des cartes équivalentes sans modification ni de la programmation du premier calculateur ni de la programmation du deuxième calculateur.
6. Robot mobile selon la revendication 1 caractérisé en ce que le deuxième calculateur peut être remplacé par un autre calculateur équivalent sans modification de la programmation du premier calculateur.
7. Robot mobile selon la revendication 1 caractérisé en ce que les communications entre le premier calculateur et les cartes électroniques sont gérées par un protocole sécurisé sur au moins un bus spécifique, ledit protocole sécurisé comportant des trames comprenant avant les octets du message un octet contenant au moins l'adresse de destination et un bit de poids fort à une valeur choisie, et après les octets du message, au moins un octet contenant la taille du message et un octet contenant un CRC.
8. Robot mobile selon la revendication 7 caractérisé en ce que tous les octets de la trame selon ledit protocole sécurisé ont un premier bit à la valeur complémentaire du bit de poids fort de l'octet d'adresse et que le premier octet tous les sept octets contient les sept bits des poids fort des sept octets suivants.
9. Robot mobile selon la revendication 7 caractérisé en ce que ledit protocole sécurisé comporte un mode de communication simulcast.
10. Robot mobile selon la revendication 7 caractérisé en ce que le premier calculateur et les cartes électroniques qu'il contrôle sont en outre connectés par au moins deux lignes de communication dont l'une permet la détection de fonctionnement et l'autre l'attribution d'adresses aux dites cartes électroniques.
11. Procédé de contrôle d'un robot mobile sur des membres articulés comprenant une pluralité de d'étapes de commandes de sous- ensembles de capteurs et d'actionneurs, chaque sous-ensemble étant commandé par une carte électronique (10), caractérisé en ce que les étapes de contrôle d'au moins une partie des cartes électroniques sont réparties entre au moins un premier calculateur (20) et un deuxième calculateur (30), ledit premier calculateur (20) assurant notamment l'étape de transmission aux dites cartes électroniques (10) de messages de commande d'exécution de fonctions dont l'étape de définition est réalisée par le deuxième calculateur (30).
12. Procédé de contrôle d'un robot mobile selon la revendication 11 caractérisé en ce que les communications entre le premier calculateur et les cartes électroniques sont gérées par un protocole sécurisé sur au moins un bus spécifique, ledit protocole sécurisé comportant des trames comprenant avant les octets du message un octet contenant au moins l'adresse de destination et un bit de poids fort à une valeur choisie, et après les octets du message, au moins un octet contenant la taille du message et un octet contenant un CRC et en ce que tous les octets de la trame selon ledit protocole sécurisé ont un premier bit à la valeur complémentaire du bit de poids fort de l'octet d'adresse et que le premier octet tous les sept octets contient les sept bit des poids fort des sept octets suivants.
13. Procédé de contrôle d'un robot mobile selon la revendication 11 caractérisé en ce que les messages de commande sont transmis aux cartes électroniques avec une période sensiblement fixe dont l'ordre de grandeur est la dizaine de millisecondes.
14. Procédé de contrôle d'un robot mobile selon la revendication 11 caractérisé en ce que les messages de commande élaborés par le deuxième calculateur comportent au moins une date d'exécution par commande.
15. Procédé de contrôle d'un robot mobile selon la revendication 14 caractérisé en ce que les valeurs des commandes datées sont calculées par interpolation aux dates d'envoi périodiques entre les valeurs juste avant et les valeurs juste après.
16. Procédé de contrôle d'un robot mobile selon la revendication 13 caractérisé en ce que les consignes d'asservissement exécutées par une carte électronique entre une première commande et une deuxième commande sont extrapolées des commandes précédentes en prolongeant la vitesse de variation de commande entre la commande précédent la première commande et ladite première commande.
17. Procédé de contrôle d'un robot mobile selon la revendication 13 caractérisé en ce que les consignes d'asservissement exécutées par une carte électronique entre une première commande et une deuxième commande sont extrapolées des commandes précédentes en translatant la vitesse de variation de commande entre la commande précédent la première commande et ladite première commande sur la consigne d'asservissement appliquée entre Ia première et la deuxième commandes.
PCT/EP2009/054177 2008-04-09 2009-04-08 Architecture de controle - commande d'un robot mobile utilisant des membres articules WO2009124951A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP09731189A EP2262623A1 (fr) 2008-04-09 2009-04-08 Architecture de controle - commande d'un robot mobile utilisant des membres articules
US12/736,456 US9327400B2 (en) 2008-04-09 2009-04-08 Control-command architecture for a mobile robot using articulated limbs
CN200980119536.2A CN102046337B (zh) 2008-04-09 2009-04-08 使用关节型四肢的移动机器人的控制指令结构
JP2011503428A JP5849345B2 (ja) 2008-04-09 2009-04-08 関節肢を使用する移動ロボットの制御コマンドアーキテクチャ
US15/082,700 US10022862B2 (en) 2008-04-09 2016-03-28 Control-command architecture for a mobile robot using articulated limbs

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0801956A FR2929873B1 (fr) 2008-04-09 2008-04-09 Architecture de controle-commande d'un robot mobile utilisant des membres articules
FR08/01956 2008-04-09

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US12/736,456 A-371-Of-International US9327400B2 (en) 2008-04-09 2009-04-08 Control-command architecture for a mobile robot using articulated limbs
US15/082,700 Continuation US10022862B2 (en) 2008-04-09 2016-03-28 Control-command architecture for a mobile robot using articulated limbs

Publications (1)

Publication Number Publication Date
WO2009124951A1 true WO2009124951A1 (fr) 2009-10-15

Family

ID=40219258

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/054177 WO2009124951A1 (fr) 2008-04-09 2009-04-08 Architecture de controle - commande d'un robot mobile utilisant des membres articules

Country Status (6)

Country Link
US (2) US9327400B2 (fr)
EP (1) EP2262623A1 (fr)
JP (1) JP5849345B2 (fr)
CN (1) CN102046337B (fr)
FR (1) FR2929873B1 (fr)
WO (1) WO2009124951A1 (fr)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2474318A (en) * 2010-05-11 2011-04-13 Jideofor Harry Nduka Humanoid robot with interchangeable legs for different terrain
WO2012000927A1 (fr) 2010-07-02 2012-01-05 Aldebaran Robotics Robot humanoide joueur, methode et systeme d'utilisation dudit robot
WO2012010437A1 (fr) 2010-07-23 2012-01-26 Aldebaran Robotics Robot humanoide dote d'une interface de dialogue naturel, procede de controle du robot et programme correspondant
WO2012025387A1 (fr) 2010-08-27 2012-03-01 Aldebaran Robotics S.A Robot humanoide dote de capacites de gestion de chutes et methode de gestion desdites chutes
WO2012079926A1 (fr) 2010-12-17 2012-06-21 Aldebaran Robotics S.A Robot humanoide dote d'un gestionnaire de ses ressources physiques et virtuelles, procedes d'utilisation et de programmation
WO2013150076A1 (fr) 2012-04-04 2013-10-10 Aldebaran Robotics Robot apte a integrer des dialogues naturels avec un utilisateur dans ses comportements, procedes de programmation et d'utilisation dudit robot
WO2013178741A1 (fr) 2012-06-01 2013-12-05 Aldebaran Robotics Systeme et procede pour generer des comportements contextuels d'un robot mobile executes en temps reel
CN106043488A (zh) * 2015-04-21 2016-10-26 电子科技大学 一种家庭服务机器人
CN109153116A (zh) * 2016-03-07 2019-01-04 软银机器人欧洲公司 机器人的模块化制造
WO2019224501A1 (fr) 2018-05-25 2019-11-28 Hoomano Dispositif et methode de mesure d'une caracteristique d'une interaction entre un utilisateur et un dispositif d'interaction

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101809973B1 (ko) * 2011-01-24 2017-12-19 삼성전자주식회사 로봇 제어 시스템 및 로봇 제어 방법
US20130085602A1 (en) * 2011-10-04 2013-04-04 Hei Tao Fung Office Robot System
TWI492343B (zh) * 2012-11-02 2015-07-11 矽品精密工業股份有限公司 半導體基板及其製法
US10418298B2 (en) * 2013-09-24 2019-09-17 STATS ChipPAC Pte. Ltd. Semiconductor device and method of forming dual fan-out semiconductor package
EP2952300A1 (fr) * 2014-06-05 2015-12-09 Aldebaran Robotics Détection de collision
CN105119985B (zh) * 2015-08-10 2019-05-03 唐思钊 一种多工位智能机器人及其控制方法
JP1545285S (fr) * 2015-08-17 2016-03-07
JP1556885S (fr) 2015-09-17 2016-08-22
US11072067B2 (en) * 2015-11-16 2021-07-27 Kindred Systems Inc. Systems, devices, and methods for distributed artificial neural network computation
USD795320S1 (en) * 2015-12-07 2017-08-22 UBTECH Robotics Corp. Entertainment robot
USD795321S1 (en) * 2015-12-07 2017-08-22 UBTECH Robotics Corp. Entertainment robot
US20170330413A1 (en) 2016-05-13 2017-11-16 Universal Entertainment Corporation Speech recognition device and gaming machine
CN105905187A (zh) * 2016-06-22 2016-08-31 北京科技大学 仿生正六边形六足机器人
CN106406328B (zh) * 2016-11-05 2020-04-03 杭州畅动智能科技有限公司 一种基于机器人开发平台的运动控制方法
CN107685788B (zh) * 2017-09-06 2023-10-27 滨州学院 一种足球机器人
CN110253567B (zh) * 2019-05-22 2021-07-20 深圳镁伽科技有限公司 用于控制机器人运动的运动控制系统、方法及机器人
TWI739604B (zh) * 2020-09-18 2021-09-11 英業達股份有限公司 訓練機器動物的運動控制器的方法
JP7553825B2 (ja) * 2021-09-10 2024-09-19 株式会社デンソーウェーブ ロボット制御システム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040015598A1 (en) * 2002-07-17 2004-01-22 D-Link Corporation Method for increasing the transmit and receive efficiency of an embedded ethernet controller
EP1486298A1 (fr) * 2002-03-18 2004-12-15 Sony Corporation Robot, controleur de robot a jambes et procede correspondant, systeme de capteurs pour robot a jambes, et appareil locomoteur
EP1825966A1 (fr) * 2004-10-15 2007-08-29 HONDA MOTOR CO., Ltd. Module de commande de robot mobile dote de jambes
US20070257910A1 (en) * 2004-03-17 2007-11-08 Steffen Gutmann Method and Apparatus for Detecting Plane, and Robot Apparatus Having Apparatus for Detecting Plane

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4734866A (en) * 1984-07-05 1988-03-29 Siemens Aktiengesellschaft Computer controller for an industrial multiaxis robot
KR100191336B1 (ko) * 1990-01-22 1999-06-15 렌나르트손켄트 분산제어 체계용 배열
JPH0538689A (ja) * 1991-07-29 1993-02-19 Toshiba Corp 多関節ロボツトの分散制御システム
US5917840A (en) * 1992-03-13 1999-06-29 Foxboro Company Protection against communications crosstalk in a factory process control system
JP2711349B2 (ja) * 1992-08-04 1998-02-10 川崎重工業株式会社 産業用ロボットの制御方法およびそれに用いる制御装置
US5285381A (en) * 1992-09-09 1994-02-08 Vanderbilt University Multiple control-point control system and method of use
JPH06284164A (ja) * 1993-03-25 1994-10-07 Mitsubishi Electric Corp 通信制御コード回避通信方法
JPH07307742A (ja) * 1994-05-16 1995-11-21 Kokusai Electric Co Ltd データ伝送方法
JPH07336366A (ja) * 1994-06-09 1995-12-22 Canon Inc 無線ｌａｎシステム
IL120889A (en) * 1997-05-22 1998-10-30 Eshed Robotec 1982 Ltd Method and facility for direct learning of vending machines
JP3926898B2 (ja) * 1997-10-16 2007-06-06 株式会社バッファロー 集線装置、集線装置のエラー通知方法および集線装置のためのエラー通知プログラムを記録したコンピュータ読み取り可能な記録媒体
JP2000099127A (ja) * 1998-09-17 2000-04-07 Nippon Telegr & Teleph Corp <Ntt> ロボットシステム用一斉同報装置および方法とそのプログラムを記録した記録媒体
JP2001150375A (ja) * 1999-11-25 2001-06-05 Sony Corp 脚式移動ロボットの制御システム
US6377013B2 (en) * 1999-12-24 2002-04-23 Honda Giken Kogyo Kabushiki Kaisha Control apparatus for legged mobile robot
JP2002113675A (ja) 2000-10-11 2002-04-16 Sony Corp ロボット制御システム並びにロボット制御用ソフトウェアの導入方法
JP2002307340A (ja) 2001-04-19 2002-10-23 Sony Corp 脚式移動ロボット及びその制御方法
JP2003334783A (ja) * 2002-05-13 2003-11-25 Canon Inc ロボットの情報制御方法
JP2004078895A (ja) * 2002-06-17 2004-03-11 Sanyo Electric Co Ltd 分散制御システムおよび分散制御方法
CN1476963A (zh) * 2002-06-17 2004-02-25 ������������ʽ���� 分布式控制系统和分布式控制方法
JP2004038855A (ja) * 2002-07-08 2004-02-05 Olympus Corp 軸操作装置、軸操作方法、及び軸操作プログラム
US6999851B2 (en) * 2002-08-30 2006-02-14 Sony Corporation Robot apparatus and motion controlling method therefor
JP2004167666A (ja) * 2002-08-30 2004-06-17 Sony Corp ロボット装置及びその動作制御方法
US7348746B2 (en) * 2003-02-14 2008-03-25 Honda Giken Kogyo Kabushiki Kaisha Abnormality detection system of mobile robot
US7038421B2 (en) * 2003-06-17 2006-05-02 International Business Machines Corporation Method and system for multiple servo motor control
US20060184280A1 (en) * 2005-02-16 2006-08-17 Magnus Oddsson System and method of synchronizing mechatronic devices
JP4280999B2 (ja) * 2004-07-02 2009-06-17 独立行政法人産業技術総合研究所 ロボットシステム
US7904182B2 (en) * 2005-06-08 2011-03-08 Brooks Automation, Inc. Scalable motion control system
JP2007038326A (ja) * 2005-08-01 2007-02-15 Toyota Motor Corp ロボット制御システム
DE102006054124B4 (de) * 2006-11-15 2009-05-28 Phoenix Contact Gmbh & Co. Kg Verfahren und System zur sicheren Datenübertragung

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1486298A1 (fr) * 2002-03-18 2004-12-15 Sony Corporation Robot, controleur de robot a jambes et procede correspondant, systeme de capteurs pour robot a jambes, et appareil locomoteur
US20040015598A1 (en) * 2002-07-17 2004-01-22 D-Link Corporation Method for increasing the transmit and receive efficiency of an embedded ethernet controller
US20070257910A1 (en) * 2004-03-17 2007-11-08 Steffen Gutmann Method and Apparatus for Detecting Plane, and Robot Apparatus Having Apparatus for Detecting Plane
EP1825966A1 (fr) * 2004-10-15 2007-08-29 HONDA MOTOR CO., Ltd. Module de commande de robot mobile dote de jambes

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2474318A (en) * 2010-05-11 2011-04-13 Jideofor Harry Nduka Humanoid robot with interchangeable legs for different terrain
WO2012000927A1 (fr) 2010-07-02 2012-01-05 Aldebaran Robotics Robot humanoide joueur, methode et systeme d'utilisation dudit robot
US9950421B2 (en) 2010-07-02 2018-04-24 Softbank Robotics Europe Humanoid game-playing robot, method and system for using said robot
US8942849B2 (en) 2010-07-23 2015-01-27 Aldebaran Robotics Humanoid robot equipped with a natural dialogue interface, method for controlling the robot and corresponding program
WO2012010437A1 (fr) 2010-07-23 2012-01-26 Aldebaran Robotics Robot humanoide dote d'une interface de dialogue naturel, procede de controle du robot et programme correspondant
WO2012010451A1 (fr) 2010-07-23 2012-01-26 Aldebaran Robotics Robot humanoide dote d'une interface de dialogue naturel, procede de controle du robot et programme correspondant
WO2012025387A1 (fr) 2010-08-27 2012-03-01 Aldebaran Robotics S.A Robot humanoide dote de capacites de gestion de chutes et methode de gestion desdites chutes
US9429948B2 (en) 2010-08-27 2016-08-30 Aldebaran Robotics Humanoid robot having fall-management capabilities, and method for managing said falls
WO2012079926A1 (fr) 2010-12-17 2012-06-21 Aldebaran Robotics S.A Robot humanoide dote d'un gestionnaire de ses ressources physiques et virtuelles, procedes d'utilisation et de programmation
US9975246B2 (en) 2010-12-17 2018-05-22 Softbank Robotics Europe Humanoid robot provided with a manager for the physical and virtual resources thereof, and methods for use and programming
WO2013150076A1 (fr) 2012-04-04 2013-10-10 Aldebaran Robotics Robot apte a integrer des dialogues naturels avec un utilisateur dans ses comportements, procedes de programmation et d'utilisation dudit robot
US10052769B2 (en) 2012-04-04 2018-08-21 Softbank Robotics Europe Robot capable of incorporating natural dialogues with a user into the behaviour of same, and methods of programming and using said robot
WO2013178741A1 (fr) 2012-06-01 2013-12-05 Aldebaran Robotics Systeme et procede pour generer des comportements contextuels d'un robot mobile executes en temps reel
CN106043488A (zh) * 2015-04-21 2016-10-26 电子科技大学 一种家庭服务机器人
CN109153116A (zh) * 2016-03-07 2019-01-04 软银机器人欧洲公司 机器人的模块化制造
WO2019224501A1 (fr) 2018-05-25 2019-11-28 Hoomano Dispositif et methode de mesure d'une caracteristique d'une interaction entre un utilisateur et un dispositif d'interaction
FR3081578A1 (fr) 2018-05-25 2019-11-29 Hoomano Dispositif et methode de mesure d’une caracteristique d’une interaction entre un utilisateur et un dispositif d’interaction

Also Published As

Publication number Publication date
EP2262623A1 (fr) 2010-12-22
US20110029128A1 (en) 2011-02-03
FR2929873B1 (fr) 2010-09-03
US10022862B2 (en) 2018-07-17
JP2011516287A (ja) 2011-05-26
CN102046337B (zh) 2015-01-21
JP5849345B2 (ja) 2016-01-27
US9327400B2 (en) 2016-05-03
US20160311109A1 (en) 2016-10-27
FR2929873A1 (fr) 2009-10-16
CN102046337A (zh) 2011-05-04

Similar Documents

Publication Publication Date Title
WO2009124951A1 (fr) Architecture de controle - commande d&#39;un robot mobile utilisant des membres articules
KR102044665B1 (ko) 로봇 시스템이 작업을 수행하기 위한 명령어를 생성하기 위한 방법 및 시스템
EP1610221A1 (fr) Dispositif fournisseur d&#39;informations, procede associe et systeme fournisseur d&#39;informations
EP2740012B1 (fr) Robot a articulations de rigidite variable et methode de calcul de ladite rigidite optimisee
US20090083589A1 (en) Systems, devices, and/or methods for managing communications
TWI259686B (en) Method of managing data read operations, article comprising a storage medium, and system and device for use with a network and an initiator coupled to the network
US8907981B2 (en) Method and system for dynamic composing and creating 3D virtual devices
CN109159125A (zh) 基于ros系统机器人的云服务系统
JP2005515903A (ja) ロボット用センサおよびアクチュエータのハードウェア抽象化層内における抽象化および集合化
US20050080514A1 (en) Content providing system
CN114327399B (zh) 分布式训练方法、装置、计算机设备、存储介质和产品
Chikurtev et al. Communication system for remote control of service robots
Babaians et al. Ros2unity3d; high-performance plugin to interface ros with unity3d engine
JP2003111981A (ja) ロボット装置及びその制御方法、ロボットのための情報提供システム及び情報提供方法、並びに記憶媒体
CN111124611A (zh) 一种机器人管理方法、机器人管理装置及电子设备
CN115880403A (zh) 针对动作捕捉数据的处理方法和系统
JP2019054455A (ja) 通信デバイス、情報通信端末装置及び通信方法
EP2297643A1 (fr) Carte electronique et systeme comportant une pluralite de telles cartes
US11461977B2 (en) Controller with reel(s) and/or other mechanism(s) for simulating force indicated in augmented or virtual reality content
Bassa Development of the communication system for a lower limb human exoskeleton using the ros middleware
WO2002015009A1 (fr) Dispositif et procede de traitement d&#39;informations et robot associe
JP2003127080A (ja) 組込み型制御用計算機
Bergeon et al. Raspberry Pi as an Interface for a Hardware Abstraction Layer: Structure of Software and Extension of the Turtlebot 2–Kobuki Protocol
Preston The definitive guide to building Java robots
US11715246B1 (en) Modification and transfer of character motion

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980119536.2

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09731189

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011503428

Country of ref document: JP

Ref document number: 12736456

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2009731189

Country of ref document: EP

ENP Entry into the national phase

Ref document number: PI0912995

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20101122