HK1237306B - Systems and methods for modular units in electro-mechanical systems - Google Patents

Description

Systems and methods for modular units in electromechanical systems

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application No. 61/991,078, filed May 9, 2014, entitled “Modularity in the Context of Snake Robots,” and U.S. Provisional Application No. 61/991,665, filed May 12, 2014, entitled “Modular Robotic Units,” both of which are incorporated herein by reference in their entireties.

This disclosure is related to U.S. Patent Application No. 14/286,316, filed May 23, 2014, the entire contents of which are incorporated herein by reference.

Technical Field

The technology described herein relates generally to electromechanical systems and, more particularly, to modular units as components for electromechanical systems.

Background of the Invention

Electromechanical devices, which involve the use of electrical signals to create mechanical motion or the use of mechanical motion to create electrical signals, have countless applications, from assembly line automation to electric typewriters to automobile starter motors. Additional applications for electromechanical devices are limited only by human ingenuity, with further implementations being developed every day. This evolving technology will benefit from modular "building blocks" from which a wide variety of electromechanical systems can be created with minimal setup and configuration.

SUMMARY OF THE INVENTION

Systems and methods for electromechanical systems are provided. A system includes a plurality of connected modules. A first module of the modules includes an actuator for imparting motion to the electromechanical system; and a data processor configured to sense a state of the first module and command the actuator to modify the state of the first module.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting a first of a plurality of connected modules that may be integrated to form an electromechanical system.

FIG. 2 is a block diagram depicting first and second connected modules, each having a degree of freedom that imparts motion to the electromechanical system.

FIG3 is a block diagram illustrating an exemplary implementation of modules of an electromechanical system.

FIG. 4 is a diagram depicting a plurality of modules integrated into a multi-legged robot having six legs.

5 is a diagram depicting another configuration of multiple modules in a serpentine configuration for an electromechanical system.

6-8 depict example modules configured to connect to other modules to form an electromechanical system.

FIG. 9 depicts an exemplary head module on the left and an exemplary tail module on the right.

10 is a diagram depicting a rotational axis with which an actuator interacts to impart motion to an exemplary module of an electromechanical system.

FIG. 11 depicts a cross-section of the exemplary module shown in FIG. 6 .

FIG. 12 depicts a block diagram for providing module motion control, for example, to the modules depicted in FIGs. 6-9 .

FIG13 is a block diagram depicting modules having modeling capabilities on its processor.

FIG14 is a block diagram depicting a module having integrated sensor data provided to a processor and other external entities.

15 is a block diagram depicting a module that communicates data to the outside via one or more lights visible externally of the module.

FIG. 16 depicts an exemplary user interface that allows an operator to perform various functions.

FIG17 is a block diagram illustrating a mechanism by which modules identify their position in a series of modules.

18-20 depict a T-slot compatible module for imparting torque to a wheel and an external component connected to the wheel.

21 is a diagram depicting an interface module that does not include internal actuators or sensors.

FIG. 22 depicts another module type in the form of a gripper module.

23-25 depict exemplary operation of the electromechanical system.

Detailed Description of the Invention

Figure 1 is a block diagram depicting a first module 100 of a plurality (2 or more) connected modules that can be integrated to form an electromechanical system. An electromechanical system, in one embodiment of the present disclosure, includes a plurality of connected modules. The first module 100 includes a body 102 in which an actuator 104 for imparting motion to the electromechanical system is positioned. The first module 100 further includes a data processor 106. The data processor 106 is configured to sense a state of the first module 100 and command the actuator 104 to modify the state of the first module 100. For example, an external entity can command the electromechanical system to assume a certain shape or perform a certain action, and the processor of the module (including the first module 100) will operate to implement the command through self-state monitoring and command of the actuator 104.

The first module 100 is connected to one or more additional modules, such as the next second connected module 108. As further discussed herein, the second module 108 is physically connected to the first module 100, for example, via a threaded collar 110. The second module 108 is further connected to the first module and, in one embodiment, to an external entity via a communication channel 112 running between the modules (e.g., modules 100, 108). In one embodiment of the present disclosure, the communication channel operates using the Ethernet standard (e.g., transmitting encrypted data and commands), wherein in one embodiment, the communication channel operates using the TCP/IP protocol. Using such a ubiquitous protocol makes it easy to set up inter-module communication and attempts to combine various readily available auxiliary hardware (e.g., sensor hardware, such as digital cameras, infrared sensors, microphones, chemical sensors). While the Ethernet standard may not guarantee the delivery of all communications on the channel in some configurations (although such guarantees can be made using other methods), the widespread existence of Ethernet hardware and the relative ease of setup make Ethernet a preferred choice over more demanding protocols such as EtherCAT in some embodiments. To facilitate communication, the first module 100 includes a three-port switch 108, through which the first module 100 can relay communications between the processors 106 of the first module 100, the second module 108, and other modules and any external entities (e.g., external entities from which commands are received). A system using a three-port switch 108 can facilitate connecting modules in a serial manner (e.g., end-to-end). In other embodiments, a switch with more ports can be implemented to facilitate non-serial connection of modules or communication integration of entities associated with modules (e.g., first module 100) (e.g., other sensors or actuators) without first traversing such data through the processor 106.

Electromechanical systems can be formed using modules such as those described herein in a variety of topologies. Certain modules can be reused in different topologies to provide the flexibility and ease of integration required for a given application. In one embodiment, some or all of the modules in the electromechanical system are identical, while in other embodiments, a variety of different types of modules are used to implement the desired electromechanical system. In one embodiment of the present disclosure, the modules, as further described herein, are intelligently programmed to detect their configuration and operate according to the detected configuration.

FIG2 is a block diagram depicting first and second connected modules, each having a degree of freedom that imparts motion to a mechatronic system. The mechatronic system includes a first module 202 and a second module 204 connected end-to-end. The connection includes a physical connection 206; and a data connection that enables communication between the modules 202, 204 and any external entities providing commands to the mechatronic system via a switch 210 via a communication channel 208. The processor 212 of the first module 202 communicates with the external entities via the communication channel 208 and further with an actuator 214, which is configured to impart motion to the first module 202 itself and further to the mechatronic system. In one embodiment of the present disclosure, other modules, such as the second module 204, also include actuators for imparting motion to those modules and further moving the mechatronic system. The actuators and the type of motion that can be imparted to the modules (e.g., 202, 204) and the larger mechatronic system can take various forms, including translational motion (e.g., expansion, contraction), rotational motion, and oscillatory motion.

In the exemplary side view of FIG2 , the first module 202 includes an actuator 214 for imparting rotational motion to a first end 216 of the first module 202 relative to a second end 218, thereby providing the module 202 with a degree of freedom of motion. In this embodiment, the actuator 214 is configured to impart torque, causing the first end 216 to rotate relative to a first axis 220, as indicated at 222. The actuator 214 can impart torque and corresponding motion to the first module 202 based on commands received from the processor 212. In addition to the first module 202 having a degree of freedom of motion and the actuator 214 being used to impart such degrees of freedom, other modules, such as the second module, may also have a degree of freedom of motion that may or may not be consistent with the degrees of freedom of the first module 202. In one embodiment of the present disclosure, the degrees of freedom of the second module 204 are orthogonal to the degrees of freedom of the first module 202. In other embodiments, the degrees of freedom of the second module 204 are not orthogonal (e.g., offset by 30, 45, or 60 degrees) to the degrees of freedom of the first module 202. In other embodiments of the present disclosure, the degrees of freedom of motion of the first module 202 can be greater or less than 90 degrees in each direction relative to the first axis 220. While the embodiment of FIG. 2 depicts each module having certain degrees of freedom, other exemplary modules can have greater, lesser, or different degrees of freedom, as further described herein.

FIG3 is a block diagram illustrating an exemplary implementation of a module for an electromechanical system. Module 302 includes a processor 304 in the form of a Cortex M4F processor. Processor 304 is configured to communicate with upstream (e.g., the second module) and downstream (e.g., the third and fourth modules) modules and external entities via an Ethernet protocol facilitated by a three-port Ethernet switch 306. The processor further responds to two serial communication interfaces 308 and 310 for communicating with adjacent (e.g., closely adjacent) upstream modules and adjacent downstream modules, respectively. Processor 304 also communicates with one or more sensors and accompanying encoders, such as sensor assembly 312. In the embodiment of FIG3 , module 302 includes an inertial measurement unit sensor, a current sensor, a voltage sensor, and a temperature sensor. In other implementations, the module may include fewer or more sensors (e.g., a video capture sensor, a microphone). Module 302 also includes components 314 and 316 that perform the functions of actuators for imparting motion to module 302. In the embodiment of Fig. 3, the actuator includes a brushless motor driver and a current motor for imparting a part of the module 302 or an object motion (e.g., rotational motion) to the module 302, embodiments of which are further described herein. The module is further configured to power each other when connected so that all modules can be powered by an external power source. The module can further include a power supply for internal power storage and can include an autonomous power generation function (e.g., via an integrated solar cell). In one embodiment, a battery module includes an internal battery for storing power and distributing the power to other modules so that the electromechanical system can operate wirelessly without access to an external power source.

The modules described herein can be assembled in countless configurations to achieve the desired electromechanical system. FIG4 is a diagram depicting multiple modules integrated into a multi-legged robot having six legs. The multi-legged robot is capable of walking and translating using its legs and can grasp objects via grippers integrated into the head module or hand module. The multi-legged robot may further include various sensors for providing data for operating the electromechanical system and for analysis by an operator (e.g., a user; or an external entity, such as a server issuing commands to the multi-legged robot). The multi-legged robot can be implemented with 1 to n legs, where n is an integer greater than 1. The six-legged robot of FIG4 includes three identical modules 402, 404, 406 connected in each leg. Each of the modules 402, 404, 406 has certain degrees of freedom, wherein in the embodiment of FIG4, the degrees of freedom of module 402 are orthogonal to the degrees of freedom of module 404. A spacer assembly 408 is positioned between modules 404 and 406, wherein the spacer assembly 408 may include hardware to propagate communications between all modules without providing actuators and imparting motion. A rigid foot module 410 is positioned at the end of each leg. The foot module 410 may not include electronic components; or, in one embodiment, may include actuators, sensors, or other hardware for implementing the desired functionality of the multi-legged robot. In one embodiment, the foot module 410 includes a force sensor. The main body module 412 facilitates communication between modules of different legs and external entities via communication ports 414, such as providing a multi-port switch for transmitting messages sent between such hardware via the Ethernet standard. In one embodiment, additional modules are incorporated into the multi-legged robot, such as a gripper module, as further disclosed herein. Such a gripper module can be attached to the main body module 412 to act as the head of the multi-legged robot for gripping or can be attached to one of the legs (e.g., the end of module 402) to operate as a hand.

FIG5 is a diagram depicting another configuration of multiple modules in a serpentine configuration for an electromechanical system. The electromechanical system of FIG5 includes 14 identical modules (e.g., module 502), each having a certain degree of freedom, wherein the movement of the degree of freedom of a particular module 502 is controlled by a processor and actuator in the module 502. The modules are physically connected in a serial manner and further connected to each other to transmit data via a data channel (e.g., Ethernet) from one module to the next along the series of modules. The serpentine configuration can translate in various ways, such as gliding motion, tumbling motion, or other rotational motions. In addition to the identical modules, the snake-like robot also includes a head module 504, which includes various sensors (e.g., cameras) and other hardware (e.g., lights) that may not be present on other modules of the snake-like robot. In one embodiment, the head module 504 includes a high-definition camera that provides live video feed, while four LEDs can be used to illuminate darker environments. In one embodiment, the camera is an off-the-shelf IP camera enabled by the Ethernet communication bus running through the modules. The serpentine tail module 506 includes a data port for connecting to external entities to receive commands and output data (including status data of the electromechanical system and detected sensor data). In one embodiment, the tail module 506 includes a magnetic structure to support an extended Ethernet tether and integrated slip rings. In such an embodiment, the tether connector supports two high-current power lines and six signal conductors.

Figures 6-8 depict an exemplary module configured to connect to other modules to form an electromechanical system. Referring to Figure 6 , the exterior of the module includes two sections 602 and 604. The first section 602 includes a data processor and an actuator for imparting motion to the module 600. The processor and actuator act in concert to impart a torque that, through rotation of a shaft 607, causes the first section 602 and the second section 604 to rotate relative to each other in a first degree of freedom, as indicated at 606. Rotation of the shaft 607 imparts a predictable shear force to the elastic elements in the first section 602, allowing the processor and actuator to impart a specific torque to the shaft to impart a predictable amount of rotation to the second section 604 relative to the first section 602. In the embodiment of Figure 6 , the actuator is capable of imparting a torque that allows the second section 604 to be rotated up to 90 degrees in either direction relative to the first section 602, providing a total of 180 degrees of motion. In one embodiment, the housing of the module is machined from 7075 aluminum and anodized red to prevent wear and corrosion.

Inter-module portions 608, 610 at either end of module 600 provide the physical and data connections between the modules when connected. In one embodiment, the inter-module portions 608, 610 comprise a rugged, tool-free design. Modules can be aligned using locating pins and matching notches. The rotatable threaded collar shown in inter-module portion 608 is held in place by a retaining ring and can be manually rotated to lock adjacent collars together via the threads shown in inter-module portion 610. In one embodiment, this connection meets IP68 submersible standards. The electrical connection between two modules can be made using a pogo pin connector on an interface board that contacts a target area on the control board of the adjacent module. This arrangement is more resistant to misalignment, where bent or broken pins can be a problem. O-rings can be included to seal the collars at both ends. Any device with matching threads, a common power cable, and common communication protocol wiring (e.g., Ethernet) can interface with the module, allowing for design and customization freedom with different types of modules.

FIG7 depicts the module in a neutral state, wherein the first section 602 and the second section are aligned and not rotated relative to each other. The view of FIG7 depicts the rotatable threaded collar and the data and power connections provided in the inter-module portion 608. FIG8 depicts a close-up view of the inter-module portion, wherein the locating pin recess 610, the data connection port 612, and the power transfer target area can be more easily visualized. FIG9 depicts an exemplary head module on the left and an exemplary tail module on the right.

Figure 10 is a diagram depicting a rotating shaft, with which an actuator interacts to impart an exemplary module motion to an electromechanical system. The actuator is configured to apply torque to the shaft 1002 positioned in the first section of the module, as shown at 602 in Figure 6, thereby rotating the second section, as shown at 604 in Figure 6. When the actuator rotates shaft 1004, elastic element 1004, such as the tapered elastic element depicted in Figure 10, has a shearing force applied thereto. The shearing force applied to the various degrees of rotation of the shaft 1002 applied to the elastic element 1004 is predictable, enabling the actuator and processor to know the torque amount imparted to the shaft 1002 to achieve the desired rotation amount of the module section. Regular recalibration operations may be performed to update the torque level necessary to achieve the desired rotation amount, for example, to address the changing conditions of the elastic element 1004 or other aspects of the module.

FIG1 depicts a cross-section of the exemplary module shown in FIG6 . As shown in FIG11 , a resilient element 1102 having a conical cross-section is embedded in the final stage of the module's gear train 1104. The resilient element 1102 comprises a conical rubber layer molded into the final stage. In some embodiments, the module includes two encoders 1106 (e.g., magnetic encoders) that measure the input and output angles of the resilient element 1102.

Calibration of the actuator can be performed using one or more models (e.g., linear models, Norton/Thevenin damping models, Buc-Wen hysteresis models), where certain parameters of the current state of the actuator can be determined, for example, based on motor current and/or internal sensors (e.g., encoders and temperature sensors). For example, calibration of the actuator is performed by measuring the motor current of the actuator's highly geared motor and using a simple linear model to estimate the torque of the elastic body 1102. The specific operating conditions for which the motor current is an accurate estimate of the output torque are determined and introduced into a recursive estimation technique (e.g., recursive least squares, unscented Kalman filter) for real-time estimation of the spring constant. Thus, the output torque of the module is estimated.

In one embodiment, the actuator utilizes a Maxon EC20 disc motor with a rated speed of 9,300 RPM. A small steel gear on the motor's output shaft transmits rotation through a gear train consisting of three steel-bronze composite gears. The cumulative gear ratio is 349:1, creating a high-torque engagement. This motor and gear train combination can deliver a maximum output torque of 7 Nm and a top speed of 33 RPM.

FIG12 depicts a block diagram for providing modular motion control, for example, to the modules depicted in FIG6-9. In the embodiment of FIG11, the module supports angular position, velocity, and torque control via cascaded PID control. In one embodiment, each PID controller operates at 1 kHz, although target setpoint updates may be less frequent (e.g., at 100-200 Hz). Independent position and velocity outer loops generate torque commands, which are combined with the desired feedforward torque to define the output torque setpoint maintained by an internal torque controller. The internal torque controller can directly compare the desired and actual output torques as the difference between two encoder positions by directly observing spring deflection. This error is used to calculate a PWM command for the motor that applies the appropriate torque to the spring and gear train input. In an exemplary proportional controller, additional functionality is added to help compensate for common gear train nonlinearities. For example, to prevent oscillations caused by gear backlash and sensor noise, a "dead band" is added, where the error is assumed to be zero. To overcome gear train static friction, a "ram" factor can be added. Maximum output limits can also be set for each controller. To mitigate saturation of the integral term, its output can be limited to the difference between the PD output and a set output level. For example, using this approach, if PD control has reached that level, the integral term can be reduced to 0.

Having processors onboard modules within an electromechanical system enables a significant amount of intelligence to be distributed among the modules. This intelligence can be used by the module processor to determine module-level states based on high-level commands from external entities, as further described herein. Module-level processing further enables modeling of certain parameters in an attempt to optimally utilize the capabilities of the module. Figure 13 is a block diagram depicting a module 1302 having modeling capabilities on its processor 1304. In one embodiment, the data processor 1304 implements a model 1306 that is used to model a physical parameter of the module without directly measuring the physical parameter. For example, the module may include a sensor that measures a second parameter that is the same or different type as the physical parameter to be modeled. Based on the modeled physical parameter, the processor 1304 can take action, such as commanding an actuator 1308 to impart motion to the module 1302 in some manner.

In one embodiment, model 1306 operates to estimate a certain temperature within module 1302. A key challenge for electromechanical systems is safely extracting as much performance as possible from their actuators 1308 without damaging the actuators. For brushless motors, the primary performance limitation is often heat buildup in the motor windings. Unfortunately, direct measurement of this temperature is difficult due to inaccessible locations. In one embodiment, the module uses online estimation of its actuator motor winding temperature to fully exploit the motor's performance range beyond its continuous duty rating. The estimated winding temperature is based on a second temperature sensor located near the motor within module 1302, the sensed current draw of the motor, and a model of the motor's internal thermal resistance and capacitance. These inputs are provided to model 1306, which outputs the model's estimated temperature. If the estimated temperature indicates a sufficiently low temperature, the actuator motor can be overloaded without risk of damage to the motor.

Models can also be used to estimate other parameters. In one embodiment, torque sensing is performed using a model. The spring constant of the elastic element is calibrated. One approach uses an unscented Kalman filter and a heuristic function that takes into account the motor's motion and current draw. A state estimator incorporates models for hysteresis and other nonlinear effects and is integrated into the firmware of module 1302. In another embodiment, the spring constant of the elastic element is modeled periodically based on certain measurements of different types of module 1302 parameters. This adjusted spring constant can then be used to determine the amount of torque to be applied to the shaft to produce the desired amount of rotation.

Modules as described herein may include various sensors for sensing their own state and the state of their environment. FIG14 is a block diagram depicting a module having integrated sensor data that is provided to a processor and other external entities. Module 1402 includes a suite of one or more sensors 1404 that transmit data to a processor 1406. In one embodiment, certain modules may include sensors for detecting the state of their associated modules (e.g., an inertial measurement unit, a 3-axis gyroscope, a 3-axis accelerometer, a 3-axis magnetometer, a voltage sensor, a temperature sensor, a current sensor, or an actuator torque sensor). Other modules may include different sensors. For example, a head module of a snake-like robot configuration may include a camera sensor. Sensor data may be consumed internally by the processor 1406 to, for example, adjust the operation of the module 1402 (e.g., the function of the actuator 1408). The module 1402 may further transmit the sensor data externally via a communication channel and switch 1410. When sending sensor data to another module or to an external entity, the module 1402 may send the sensor data in packets using the Ethernet standard, where a single packet may contain data from multiple sensors 1404 of the module.

In addition to transmitting data via communication channels operating between modules, modules can transmit data externally in other ways. For example, a module may include wireless communication capabilities for transmitting data to other modules or to external entities. Figure 15 is a block diagram depicting a module 1502 that transmits data to the external environment via one or more lights 1504 visible from the module's exterior. The lights are external to module 1502 and detectable via an external light sensor 1506. Based on the light detected by sensor 1506, the external entity or other module can receive data from module 1502 or detect the status of module 1502. For example, light 1504 can turn on when the module is powered, such that the detection of such light at 1506 indicates that module 1502 is on to the external entity. In another embodiment, the light is located at a specific location on module 1502 such that the detection of light at 1506 (or the inability to detect light because the light is directed away from the sensor) provides data to the external entity regarding the orientation of module 1502. Multiple lights of different colors can be positioned at specific points on the module 1502 to give further detail about the orientation of the module. The light can also be varied in wavelength, brightness, or pulsed to indicate module 1502 status data or other data that the module 1502 wishes to transmit, such as values extracted from a sensor of the module 1502.

The modules can be configured with certain firmware that provides instructions to the onboard processor and other components. In one embodiment, the firmware core is a real-time operating system (RTOS) that is configured to separate the establishment and maintenance of various hardware modules into separate threads. In one embodiment, ChibiOS/RT is selected for its ready-made support for STM32Cortex processors and a hardware abstraction layer that supports peripheral devices such as Ethernet, serial, analog-to-digital conversion, and pulse width modulation. The low-level control code can include a 1kHz cascaded PID loop for simultaneous control of position, speed, and torque; a steady-state Kalman filter for actuator speed; multiple sensor readings, including two encoders and an internal IMU; a thermal model for motor winding temperature; and confirmation of adjacent modules to automatically discover the configuration of the mechatronic system.

Modules can be configured to communicate with each other and with external client software via a messaging protocol, such as Google Protocol Buffer messages. Protocol Buffers define a fixed serialization format for typed data structures supported across multiple computing platforms. The Google C++ library for Protocol Buffers can be ported to ChibiOS to enable message encoding and decoding on the module. In one embodiment, remote procedure calls (RPCs) are used. In another embodiment, a single "meta" message is defined that defines multiple optional fields that can encode module parameters and data streams. A computing environment with Protocol Buffer support can then interact with the mechatronic system by sending and receiving these meta messages. Such a protocol can be implemented as essentially stateless, and messages can be transactional, naturally supporting multiple concurrent asynchronous connections. The protocol can be equally exposed via Transmission Control Protocol (TCP) sockets, User Datagram Protocol (UDP) sockets, and serial interfaces between modules, allowing for a variety of flexible communication strategies to be used in various situations, depending on available bandwidth, the required level of control, and the interface hardware. Modules can disseminate local information, such as their configuration, by exchanging data with neighboring modules over the serial interface.

Mechatronic systems can leverage certain software architectural styles as the foundation of their frameworks. The first, the pipes and filters style, is a data flow pattern often found in systems that process real-time data. This style typically consists of two elements: filters that apply incremental transformations to the data stream, and pipes, which act as unidirectional connectors between filters. Filters are unaware of the identities of other filters and share no state with each other.

In one embodiment, the Lightweight Communication and Marshalling (LCM) framework is used as a messaging framework for inter-process communication. LCM is a low-latency publish-subscribe implementation that uses UDP multicast as the basis for broadcasting messages to components. Using multicast means that, unlike TCP-based messaging services, LCM does not require a centralized manager to forward data to the appropriate subscribers. This enables components to communicate directly and to start and stop at any time and in any order. This lower overhead can be achieved under the premise of guaranteed delivery. In one embodiment, such guaranteed delivery can be restored using other mechanisms. Communications that require reliable delivery (such as the reliable delivery provided by TCP) can be handled using other mechanisms. LCM supports multiple languages, including C, C++, Java, Python, and MATLAB, and supports Windows, Linux, Mac, and some embedded platforms.

For the control and estimation of robotic systems, typical filters (such as those for pose estimation or high-level autonomous control behaviors) can be more effective if their internal states and parameters are visible to and dynamically modifiable by human operators at runtime. This allows for more efficient debugging and parameter tuning, and is often required in the context of supervised autonomy. For these reasons, a standard way of interfacing with various filter elements at runtime can be employed, even when there is no a priori knowledge of the active components and their internal parameters. To further complicate the challenge, filters can vary significantly in purpose, approach, and even the language in which they are implemented. For example, MATLAB can be used for prototyping and development of filters and controls with complex mathematical operations, C/C++ can be used for stable code with significant performance requirements, and Java can be used for filters that need to run across platforms.

To address this issue, the system can define the concept of behaviors or filter blocks with common interface elements, called behavior parameters, which are visible and modifiable at runtime through an event bus. While this can use the same publish-subscribe framework as the pipe and filter structure mentioned earlier, it can be conceptually different. A behavior parameter is a simple data object that combines a typed variable and the allowed range of its values (allowing constraints, such as limiting PID constants to strictly positive numbers). The system can dedicate two event channels to the behavior mechanism. The first is a parameter change channel, on which parameter change events will be published. Behaviors listen to this channel and react to the events they are targeted to. The second channel is a behavior state broadcast channel, on which individual behaviors publish their full internal state when one of their parameters changes or on request.

In one embodiment, the system implements behaviors in C++, Java, and MATLAB. Figure 16 depicts an exemplary user interface that allows an operator to: observe any running behaviors on the network; stop active behaviors; start known inactive behaviors; and view and change behavior parameters using appropriate controls. Such an interface allows for a simple and versatile way to modify internal behavior parameters without modifying the underlying code.

The firmware and/or software encoded on the module can perform various functions. Such firmware and/or software at the module level can be updated as needed or as desired via updates transmitted over a module communication channel (e.g., an Ethernet channel described in certain embodiments herein). In one embodiment, a module can be configured to perform operations to confirm its configuration in an electromechanical system. For example, in an electromechanical system having a series of connected modules, the modules can be configured to determine the order in which they appear in the series (e.g., first, second, third in a snake or leg of an electromechanical system). This detection can replace manual confirmation (e.g., manual setting of an IP address), thereby achieving faster and more flexible plug-and-play setup.

Figure 17 is a block diagram that depicts a mechanism for modules to confirm their position in a series of modules. The figure depicts multiple modules 1702, 1704, 1706, each of which includes a switch 1703, 1705, 1707. The modules 1702, 1704, 1706 are connected to an external entity 1708 from which they receive commands. In one embodiment, the external entity 1708 issues commands to the modules 1702, 1704, 1706 to confirm the module's position in the series. Once a module knows its position, it can respond to commands and data directed to it from the external entity 1708 or other modules. In one embodiment, the modules 1702, 1704, 1706 and the external entity 1708 are configured to detect the number (n) of modules incorporated into the system and the position of these modules in the system. This can be achieved by instructing all modules 1702, 1704, 1706 to open the input ports of their switches 1703, 1705, 1707 and close the output ports of those switches. The external entity 1708 transmits a signal (e.g., a packet indicating that this is a message for the first module) along the communication channel running through the series of modules 1702, 1704, 1706. Only the first module 1702 will receive this signal because the outbound port of switch 1703 is closed. When the first module 1702 receives the signal, it stores an indicator indicating that it is the first module in the series. The first module 1702 then opens the outbound port of its switch 1703 and sends an acknowledgment to the external entity 1708. The external entity 1708 then sends a second signal, which is received by the first module 1702 and the second module 1704. The first module, already identified as the first in the queue, ignores the signal, while the second module 1704 recognizes that it is the second in the queue and stores an indicator of this fact. The second module 1704 opens the outbound port of its switch 1705 and sends an acknowledgment message to the external entity 1708, and the process repeats. This process is repeated until the external entity 1708 no longer receives an acknowledgment message. Based on this lack of acknowledgment messages, the external entity 1708 then knows the number of modules in the connected module series (e.g., 3).

In other embodiments, other mechanisms may be used for modules to confirm their topology and ordering. In one embodiment, a module is configured to change operating characteristics (e.g., switching transmit and receive ports on a serial interface), where adjacent modules can detect the changed characteristics and determine their relative positioning.

Modules in electromechanical systems can take a variety of forms. Figures 18-20 depict a T-slot compatible module for imparting torque to a wheel and external components connected to the wheel. The T-slot compatible module as depicted in Figure 18 is compatible with existing T-slot compatible hardware, where the module includes T-slots on all four sides to facilitate connection. In one embodiment, the module utilizes standard T-slot aluminum (e.g., compatible with 80/20 brand 10 series products) and uses a standard 1-inch bolt pattern to enable connection to existing setups and new designs with little time and effort.

The T-slot compatible module includes an integrated servo actuator for imparting torque to the wheel portion 1802 of the module. Hardware can be attached to the wheel portion 1802, for example, via an integrated screw receiver. The actuator applies torque to the wheel portion 1802, which imparts rotational motion to a rotatable body connected to the wheel portion. The T-slot compatible module can be physically connected to other modules and used for data communication. At the electrical level, communication can be handled over standard Ethernet using Google's extensible protocol buffer protocol. The module can include sensors that enable 3-axis inertial measurement, controllable motor speed, and high-bandwidth controllable torque output through a dual encoder series elastic stage after the gear train.

FIG19 is a block diagram illustrating exemplary components of the T-slot-compatible module of FIG18 . Module 1902 includes a processor 1904 configured to communicate with an external portion of module 1902 via a communication channel 1906 . Actuator 1908 responds to processor 1904 to impart motion to module 1902 by rotating a wheel portion 1910 of module 1902 upon command. Wheel portion 1910 is configured to have an external component 1912 connected thereto (e.g., via screws or other fasteners) such that rotation of wheel portion 1910 also rotates external component 1912. In one embodiment, the position of wheel portion 1910 is monitored (e.g., as part of a feedback loop to processor 1904) to maintain proper positioning of wheel portion 1910. In one embodiment, such position sensing is performed using a pair of sensors: a low-resolution first sensor 1914 and a high-resolution second sensor 1916. The low-resolution first sensor 1914 indicates the starting position of the wheel portion 1910, for example, optically using a color wheel positioned on the interior-facing surface of the wheel portion 1910, where the color at a certain position is observed by the first sensor 1914. The high-resolution second sensor 1916 precisely measures rotation starting at the initial position detected by the first sensor 1914. Combined, the measurements from these two sensors 1914, 1916 are used by the processor 1904 to determine the current position of the wheel 1910. FIG20 is a photograph depicting a crossbar 2002 connected to a module 2004 having a rotatable wheel portion that is rotated by an actuator. The crossbar 2002 is connected to the module 2004 via brackets and screws 2006. While the embodiment of FIG18-20 depicts torque imparted to the wheel portion of the module, in other embodiments, torque and rotation can be imparted to other structures of the module, as well as to external structures connected to the module.

Modules may also take various other forms. FIG21 is a diagram depicting an interface module that does not include internal actuators or sensors. Similar to the other modules described herein, the module 2102 of FIG21 includes a processor 2104; and a switch 2106 that interacts with a communication channel to communicate with other modules or external entities. The module 2102 of FIG21 further includes a communication port 2108. External actuators or sensors can be connected to the communication port 2108 (e.g., via a USB connection) to provide additional capabilities to the electromechanical system. In one embodiment, such external peripheral devices can be incorporated into the system in a plug-and-play manner, thereby communicating with other entities via an Ethernet communication channel, providing a high degree of system customization.

Figure 22 depicts another module type in the form of a gripper module. The gripper module 2202 includes an interface portion 2204 for facilitating physical and data connections with other modules or other external entities. The gripper portion includes two blades 2206, 2208, which can be controllably manipulated to perform desired functions (e.g., gripping functions) via a processor and an actuator. In the embodiment of Figure 22, the first blade 2206 is rigidly attached to the gripper module 2202 and does not move. The second blade 2208 is connected to the gripper module 2202 via a shaft 2210, which can be rotated by an actuator inside the gripper module 2202. The module 2202 may include various sensors for enhancing the operation of the gripper module 2202. A torque sensor may be combined with an internal elastic actuator to provide feedback on whether the second blade 2208 has been moved to the desired position. A force sensor may be combined to sense the amount of force sensed by one of the blades. This force limitation in the control algorithm operated by the processor within the gripper module 2202 can achieve gentle gripping of the gripper module without damaging the module 2202 or the object being grasped. The gripper module 2202 can be incorporated into a variety of mechatronic systems, including the multi-legged robot of FIG4 , where the gripper module can operate as a head module (e.g., a mouth) or at the end of one or more legs (e.g., as one (or more) hands).

23-25 illustrate exemplary operations of an electromechanical system. FIG23-24 depicts an electromechanical system 2302 coupled to a fork 2304 configured to pierce food onto the fork 2304 and

The food is translated toward the person's mouth. The embodiment of Figures 23-24 depicts a soft real-time/hard real-time software configuration. The system is trained by manually positioning the electromechanical system 2302 in multiple positions (e.g., piercing the food, three positions along the translation toward the mouth, and the final position of removing the food with the mouth as depicted in Figure 24). These positions of the electromechanical system are recorded by an external entity. The external entity then commands the playback of these positions as soft real-time commands to the modules of the electromechanical system 2302. These soft real-time commands indicate the result to be achieved (i.e., the electromechanical system at one of the recorded positions). The processors of the modules of the electromechanical system 2302 are configured to achieve the commanded position based on self-sensing of their current position and configuration. The module processors issue commands to their actuators as hard real-time commands that must be completed within a known time period, where the consistent operation of those actuators produces the desired system 2302 configuration.

FIG25 depicts an electromechanical system 2502 configured to rotate in a plane, as shown at 2504. A sensor in one of the modules of system 2502 detects an obstruction provided by hand 2506 in the embodiment of FIG25 . This sensing can be performed in various ways, such as sensing the increased torque required to provide the commanded motion, accelerometers, vibration sensing, or other methods. In one embodiment, upon sensing an unexpected system event (e.g., due to a hand interruption), the modules of system 2502 are configured to take protective actions to mitigate damage to system 2502 or obstacle 2506. For example, system 2502 can be configured to stop, reverse, or determine a different path to reach its programmed command endpoint to preferably maintain the safety of system 2502 and obstacle 2506. Thus, in one embodiment, an anomaly detected by a sensor on one module can be exploited globally within the electromechanical system, which, in one embodiment, results in coordinated actions based on the detected anomaly.

This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to make and use the invention. The patentable scope of the invention may include other examples that occur to those skilled in the art.

Claims (36)

1. An electromechanical system comprising: Multiple connected modules, the first module of which includes: An actuator, which is used to give motion to the electromechanical system; A data processor is configured to sense the state of the first module and command the actuator to modify the state of the first module to complete the received command; A three-port switch, wherein the first port is configured to communicate with the second module, the second port is configured to communicate with the third module, and the third port is configured to communicate with the data processor; The first module is configured to determine its position in a series of at least two connected modules, wherein the first module is configured to determine its position by detecting a change in the configuration characteristics of a second module that is directly connected to the first module. 2. The system of claim 1, wherein at least two of the connected modules are identical modules. 3. The system of claim 1, wherein the first module is configured to have a certain degree of freedom in the first plane; The second module connected to the first module is configured to have a certain degree of freedom in a second plane different from the first plane. 4. The system of claim 3, wherein the second plane is orthogonal to the first plane. 5. The system of claim 3, wherein the first end of the first module is configured to rotate relative to the second end of the first module in the first plane. 6. The system of claim 1, wherein the first module further includes an interface for implementing physical and data connections to a second module connected to the module. 7. The system of claim 6, wherein the interface of the first module includes a threaded collar configured to connect to the interface of the second module. 8. The system of claim 6, wherein the first module is configured to communicate with the second module via an Ethernet standard. 9. The system of claim 8, wherein the first module is further configured to communicate with an external entity via the Ethernet standard; All communication between the first module, the second module, and the external entity is conducted via the Ethernet standard. 10. The system of claim 1, wherein the system is configured to operate using 2 to N connected modules, where N is an integer greater than 2. 11. The system of claim 1, wherein the system is configured to detect the number n of modules of the connection incorporated into the system, wherein n is an integer greater than 2, and wherein the first module is configured to determine its position among a series of modules of at least two connections. 12. The system of claim 1, wherein the first module is configured to determine its position among a series of at least two connected modules, wherein the first module is configured to determine its position by: During initialization, enable the input port to the first module and disable the output ports of the first module and other modules in the series; The signal is transmitted from an external entity to the initial module in the series of modules, wherein only the initial module will receive the signal based on the disabled output port of the first module; Store an indicator that it is module number one at the initial module location; Enable the output port of this initial module; A second signal is transmitted from the external entity, wherein the initial module and the immediately following module receive the second signal based on the disabled output port of the subsequent module; The module that follows stores an indicator that it is module number two. 13. The system of claim 1, wherein the change in configuration characteristics is the switching of the transmit and receive channels at the second module. 14. The system of claim 1, wherein the data processor implements a model for modeling the physical parameters of the first module based on a second parameter of a different type from the physical parameters of the first module, wherein the data processor is configured to command the actuator based on the modeled physical parameters. 15. The system of claim 14, wherein the physical parameter is a temperature parameter, and wherein the data processor is configured to cause the actuator to exceed a threshold overload based on a modeled temperature parameter below a predefined level. 16. The system of claim 14, wherein the physical parameter is the spring coefficient of the elastic component of the actuator, wherein the first module is configured to periodically calibrate to adjust the spring coefficient. 17. The system of claim 16, wherein the data processor is configured to command the actuator to apply torque to the elastic member based on the desired position of the first module and the adjusted spring coefficient. 18. The system of claim 1, wherein the first module is configured to transmit sensor data from a plurality of sensors to an external entity in the form of packets, wherein a single packet contains data from the plurality of sensors associated with the first module. 19. The system of claim 1, wherein the system is further configured to include a unique module that is different from all other modules. 20. The system of claim 1, wherein the system is configured to include a module comprising a servo actuator configured to apply torque to a wheel portion of a servo actuator module. 21. The system of claim 20, wherein the wheel portion is configured to be connected to a rotatable body. 22. The system of claim 1, wherein the system is configured to include a module comprising a servo actuator configured to apply torque to a wheel portion of a servo actuator module, wherein the wheel portion is configured to be connected to a rotatable body; The state of this wheel section is detected based on initial low-resolution measurements and multiple subsequent high-resolution measurements. 23. The system of claim 22, wherein the low-resolution measurement confirms the approximate position of the wheel portion, and wherein the high-resolution measurement confirms the rotation of the wheel portion originating from the approximate position. 24. The system of claim 1, wherein the system is configured to include a module comprising a servo actuator configured to apply torque to a wheel portion of a servo actuator module, wherein the servo actuator module includes a plurality of T-slot frame portions. 25. The system of claim 1, wherein the first module includes one or more lights, and a camera outside the first module determines the state of the first module based on the one or more lights. 26. The system of claim 25, wherein the state is determined based on the color, brightness, or flash of the one or more lights. 27. The system of claim 1, wherein a first command is transmitted from an external entity to the first module as a soft real-time command, wherein, based on the first command, the data processor issues a second command to the actuator as a hard real-time command. 28. The system of claim 1, wherein a first command is transmitted from an external entity to the first module, the command relating to a final result of the system comprising the plurality of connected modules, wherein the data processor of the first module and data processors of other modules determine intermediate commands for relevant actuators to achieve the final result. 29. The system of claim 1, further comprising a head module connected to exactly one of the connected modules, wherein the head module includes one or more sensors not included on the connected module. 30. The system of claim 29, wherein the head module includes a camera sensor. 31. The system of claim 1, further comprising a tail module connected to exactly one of the connected modules, wherein the tail module includes a communication mechanism for communicating with an external entity, wherein the communication mechanism is a wired or wireless communication mechanism. 32. The system of claim 1, wherein communication between the connected modules or between an external entity and the first module is encrypted. 33. The system of claim 1, further comprising an interface module, wherein the interface module is connected to one of the connected modules, wherein the interface module does not include full degrees of freedom, and wherein the interface module includes one or more ports for connecting to a sensor or actuator. 34. The system of claim 1, wherein the first module is configurable to connect with other modules to form a snake-like robot; and wherein the first module is configurable to connect with other modules to form a multi-legged robot having 1 to n legs, wherein n is an integer greater than 1. 35. The system of claim 1, wherein the electromechanical system is a robot. 36. The system of claim 1, wherein the electromechanical system is a system used in automation.