The problem of self-repair is to restore functionality to a SR robot, without outside intervention, in response to module failure. Our strategy is to detect the failure, eject the failed module from the system, and replace it with a spare built into the robot’s structure. Path planning in this problem is based on finding rectilinear paths that minimize the number of turns. Our 3D-MBP algorithm addresses this issue, and in this section we describe how 3D-MBP is applied to the self-repair application. This technique is also a type of reconfiguration algorithm for systems with limited heterogeneity.
The Crystal’s motion planning based on virtual module relocation reduces to finding a rectilinear path through the robot structure. Each segment of the path can be executed in constant time, assuming no failed modules, so an efficient motion plan requires a rectilinear path of minimum bends. Replacing a failed module (filling a “hole” in the structure) can be solved using virtual module relocation. To eject a failed module, this planning technique can not be used directly since here a particular module must be actually pushed (or pulled) to a position on the surface of the robot. However, pushing gaits to move the failed module, also exhibit the property that turns are more expensive than straight line motion. To find path of a minimum-bend is therefore useful in both steps.
An MBP problem is constructed by modeling the source and destination points in module coordinates, and holes and concavities This motion planning technique leads to a 2D self-repair solution, and easily extends to 3D given an efficient shortest path algorithm. A 3D rectilinear path is able to be decomposed into a sequence of 2D turns (not all of which are in the same plane). Therefore, given a 3D rectilinear path, a motion plan can be constructed by iterating the appropriate module gait over each path segment. Note that pushing gaits require a minimum amount of supporting structure, but we can build this into the path planning problem by growing the obstacles (holes in the structure and boundaries) by the required amount. This ensures that any path returned by the algorithm is feasible.
Blog about Robotics Introduction, news of the robot, information about the robot, sharing knowledge about the various kinds of robots, shared an article about robots, and others associated with the robot
Function of Simulink File of SCARA Robot
Function (m-file .m or Simulink file .mdl) description as below:
Main.m
It is permits to open one user interface to simulate the robotics system with or without using Simulink blocks. One graphical representation of the robot SCARA 2dof as well as the possibility to animate it is accessible via this interface. This interface permits also to recover the mouse events. In this case, the mouse will allow you, in the setting of your Lab, to give position set-point (x, y) to be reached by the end-effector.
ForwardKinematics.m
Defines the positions (xT, yT) of the SCARA end-effector according to its joints coordinates.
InverseKinematics.m
Defines the joints coordinates of the SCARA according to the position of its end-effector. The output function gives [Q1, Q2, err] with Q1 the solution when .2>0 (low elbow), Q2 the second solution. To satisfy some constraints linked to the robot workspace one imposes that:
• The position of the end-effector belongs to the working space
• The values of .1 and .2 vary in the robot joint domain (i.e. 0°=.1=180°;
• 180°<.2<180°).
Thus InverseKinematics.m function gives: err(1)=0 if the first solution Q1 is possible and =1 if the solution is not possible, and in the same way err(2) indicates the feasibility of the second solution.
InverseKinematicsUsingGeometry.m
Defines, using simple geometrical construction, the joint coordinates of the SCARA according to the position of its end-effector.
SetPointTrajectory.m
Gives the set-point to follow by the robot end-effector in the work space domain.
GUI_Management.m
Manage all events (click of mouse, pressed button, etc.) of the GUI (Graphical User Interface) window.
SetDispaly.m
Updates the graphical representation of the SCARA robot as well as the display of the joint information and the position of the end-effector.
SimulinkRobotControlWithoutDyMo.mdl
Simulink model that permits while interfacing it with the programs described above to control the movement of the SCARA in order to follow for example a trajectory.
Main.m
It is permits to open one user interface to simulate the robotics system with or without using Simulink blocks. One graphical representation of the robot SCARA 2dof as well as the possibility to animate it is accessible via this interface. This interface permits also to recover the mouse events. In this case, the mouse will allow you, in the setting of your Lab, to give position set-point (x, y) to be reached by the end-effector.
ForwardKinematics.m
Defines the positions (xT, yT) of the SCARA end-effector according to its joints coordinates.
InverseKinematics.m
Defines the joints coordinates of the SCARA according to the position of its end-effector. The output function gives [Q1, Q2, err] with Q1 the solution when .2>0 (low elbow), Q2 the second solution. To satisfy some constraints linked to the robot workspace one imposes that:
• The position of the end-effector belongs to the working space
• The values of .1 and .2 vary in the robot joint domain (i.e. 0°=.1=180°;
• 180°<.2<180°).
Thus InverseKinematics.m function gives: err(1)=0 if the first solution Q1 is possible and =1 if the solution is not possible, and in the same way err(2) indicates the feasibility of the second solution.
InverseKinematicsUsingGeometry.m
Defines, using simple geometrical construction, the joint coordinates of the SCARA according to the position of its end-effector.
SetPointTrajectory.m
Gives the set-point to follow by the robot end-effector in the work space domain.
GUI_Management.m
Manage all events (click of mouse, pressed button, etc.) of the GUI (Graphical User Interface) window.
SetDispaly.m
Updates the graphical representation of the SCARA robot as well as the display of the joint information and the position of the end-effector.
SimulinkRobotControlWithoutDyMo.mdl
Simulink model that permits while interfacing it with the programs described above to control the movement of the SCARA in order to follow for example a trajectory.
Reconfiguration Planning of Self-Robotic System
The transforming task of a modular system from one configuration into another is called the Reconfiguration Planning problem. Solving this problem is fundamental to any SR system. In some approaches explicit start and goal configurations are given, and in others the goal shape is defined by desired properties. Centralized algorithms require global system knowledge and compute reconfiguration plans directly, whereas decentralized algorithms compute solutions in a distributed fashion without the use of a central controller.
Reconfiguration algorithms can be designed for classes of modules, or for specific robots. Often a centralized solution is more obvious and is developed first, followed by a distributed version, although not always. Not all decentralized algorithms are guaranteed to converge to a solution, or are correct for arbitrary goal shapes.
Reconfiguration of CEBOT was planned by a central control cell known as a master. Master cells were later intended to be dynamically chosen, blurring the distinction between centralization and decentralization. Later CEBOT control is hierarchical (behavior-based). A common technique is used in reconfiguration algorithms for a lattice-based system is to build a graph representation of the robot configuration, and then to use standard graph techniques such as search to compute motion plans. Planning for the Molecule robot developed by the Dartmouth group is one example. Other example from the Dartmouth group is planning for unit-compressible systems such as the Crystal. This planner, named MeltGrow, uses the concept of a metamodule , where a group of modules are treated as a single unit with additional motion capabilities. The Crystal robot implements convex transitions using metamodules called Grains. Graph-based algorithms are also used by the MTRAN planner to compute individual module trajectories.
Pre-computed data structures can also be centralized by planners store such as gait-control tables. Once a gait is selected by the central controller, it is executed by local controllers on the individual modules. This type of algorithm is used by Polypod. The division between central and local controllers is also used in by RMMS, and I-Cubes.
Reconfiguration algorithms can be designed for classes of modules, or for specific robots. Often a centralized solution is more obvious and is developed first, followed by a distributed version, although not always. Not all decentralized algorithms are guaranteed to converge to a solution, or are correct for arbitrary goal shapes.
Reconfiguration of CEBOT was planned by a central control cell known as a master. Master cells were later intended to be dynamically chosen, blurring the distinction between centralization and decentralization. Later CEBOT control is hierarchical (behavior-based). A common technique is used in reconfiguration algorithms for a lattice-based system is to build a graph representation of the robot configuration, and then to use standard graph techniques such as search to compute motion plans. Planning for the Molecule robot developed by the Dartmouth group is one example. Other example from the Dartmouth group is planning for unit-compressible systems such as the Crystal. This planner, named MeltGrow, uses the concept of a metamodule , where a group of modules are treated as a single unit with additional motion capabilities. The Crystal robot implements convex transitions using metamodules called Grains. Graph-based algorithms are also used by the MTRAN planner to compute individual module trajectories.
Pre-computed data structures can also be centralized by planners store such as gait-control tables. Once a gait is selected by the central controller, it is executed by local controllers on the individual modules. This type of algorithm is used by Polypod. The division between central and local controllers is also used in by RMMS, and I-Cubes.
Chain-based Robots
Modules aggregate as connected 1D strings of units in chain-based systems. This class of robots easily implements rolling or undulating motions as in snake robots or legged robots. However, control is much more difficult for chain-based systems than for lattice-based systems because of the continuous nature of the actuation: modules can move to any arbitrary position as opposed to a fixed number of neighbor positions in a lattice. Our previous work has not considered chain-based systems, but it is important to understand their characteristics in the interest of developing more generalized algorithms.
Polypod was the first prominent chain-based system, proposed by Yim in 1993. Polypod is made up of Segments, which are actuated 2-DOF 10-bar linkages, and Nodes, which are rigid cubes housing batteries. Multiple gaits for locomotion, including rolling, legged, and even Moonwalk gaits, were demonstrated with Polypod. Polybot succeeds Polypod, sharing the same bipartite structure. Segments in Polybot abandon the 10-bar linkage in favor of a 1-DOF rotational actuator. The latest generation of Polybot prototypes has on-board processing and CANbus (controller area network) hardware for communication. A system that uses a similar actuation design is CONRO (CONfigurable RObot). The CONRO module has two rotational degrees of freedom, one for pitch and one for yaw, and was designed with particular size and weight considerations. Considerable attention has been paid to the connection mechanism, which is a peg-in-hole connector with SMA (shape-memory alloy) latching mechanism that can be disconnected by either face. Computation is on-board each module, so unlike Polypod, CONRO has only one module type. Power can be provided externally or via batteries on later prototypes. Manually configured shapes examples are the snake and the hexapod, and the current CONRO system is designed for self-reconfiguration.
The DRAGON is a robot snake with torsion-free (constant-velocity) joints. A sophisticated connector has been developed for the DRAGON, designed for strength and tolerance for docking.
Polypod was the first prominent chain-based system, proposed by Yim in 1993. Polypod is made up of Segments, which are actuated 2-DOF 10-bar linkages, and Nodes, which are rigid cubes housing batteries. Multiple gaits for locomotion, including rolling, legged, and even Moonwalk gaits, were demonstrated with Polypod. Polybot succeeds Polypod, sharing the same bipartite structure. Segments in Polybot abandon the 10-bar linkage in favor of a 1-DOF rotational actuator. The latest generation of Polybot prototypes has on-board processing and CANbus (controller area network) hardware for communication. A system that uses a similar actuation design is CONRO (CONfigurable RObot). The CONRO module has two rotational degrees of freedom, one for pitch and one for yaw, and was designed with particular size and weight considerations. Considerable attention has been paid to the connection mechanism, which is a peg-in-hole connector with SMA (shape-memory alloy) latching mechanism that can be disconnected by either face. Computation is on-board each module, so unlike Polypod, CONRO has only one module type. Power can be provided externally or via batteries on later prototypes. Manually configured shapes examples are the snake and the hexapod, and the current CONRO system is designed for self-reconfiguration.
The DRAGON is a robot snake with torsion-free (constant-velocity) joints. A sophisticated connector has been developed for the DRAGON, designed for strength and tolerance for docking.
Lattice-based Robots Hardware
Modules are constrained to occupy positions in a virtual grid, or lattice in lattice-based systems. One of the simplest module shapes in a 2D lattice based system is a square, but more complex polygons such as a hexagon (and a rhombic dodecahedron in 3D) have also been proposed. Because of the discrete, regular nature of their structure, developing algorithms for lattice-based systems is often easier than for other systems. The grid constraint makes implementing certain rolling motions, such as the tank-tread, more challenging since module attachment and detachment is required. We would like to develop algorithms implementable by most, or all, lattice-based systems, so a complete review of their properties is essential.
One of the first lattice-based SR robots planned and constructed in hardware is the Fracta robot. The 2D Fractum modules link to each other using electromagnets. Communication is achieved through infrared devices embedded in the sides of the units, and allows one fractum to communicate with its neighbors. Computation is also onboard; each fractum contains an 8-bit microprocessor. Power, however, is provided either through tethers or from electrical contacts with the base plane.
This system was designed for self-assembly, and can form simple symmetric shapes such as a triangle, as well as arbitrary shapes. Other lattice-based robots include a smaller 2D system, and a 3D system. Another early SR robot is the Metamorphic Robot. The basic unit of this robot is a six-bar linkage forming a hexagon. The kinematics of this shape was investigated when the design was proposed, and hardware prototypes were constructed later. A unique characteristic of this system is that it can directly implement a convex transition; a given module can move around its neighbor with no supporting structure.
The hexagon deforms and translates in an owing motion. A square shape with this same property was also proposed. This motion primitive is important since it is required by many general reconfiguration algorithms, but many systems can only implement it using a group of basic units working together.
One of the first lattice-based SR robots planned and constructed in hardware is the Fracta robot. The 2D Fractum modules link to each other using electromagnets. Communication is achieved through infrared devices embedded in the sides of the units, and allows one fractum to communicate with its neighbors. Computation is also onboard; each fractum contains an 8-bit microprocessor. Power, however, is provided either through tethers or from electrical contacts with the base plane.
This system was designed for self-assembly, and can form simple symmetric shapes such as a triangle, as well as arbitrary shapes. Other lattice-based robots include a smaller 2D system, and a 3D system. Another early SR robot is the Metamorphic Robot. The basic unit of this robot is a six-bar linkage forming a hexagon. The kinematics of this shape was investigated when the design was proposed, and hardware prototypes were constructed later. A unique characteristic of this system is that it can directly implement a convex transition; a given module can move around its neighbor with no supporting structure.
The hexagon deforms and translates in an owing motion. A square shape with this same property was also proposed. This motion primitive is important since it is required by many general reconfiguration algorithms, but many systems can only implement it using a group of basic units working together.
Hardware Design Pioneering Research
To build reconfiguring robots in hardware involves designing and constructing the basic modular units that combine to form the robot itself. Such modules differ from the wheels, arms, and grippers of fixed architecture robots in that they are functional only as a group as opposed to individually. Because we are interested in developing general algorithms for classes of robots instead of particular systems, familiarity with the entire spectrum of existing systems is valuable. Current systems can be divided into classes based on a number of module properties. Systems composed of a single module type are known as homogeneous systems, and those with multiple module types are called heterogeneous systems.
Modules can connect to each other in various ways, and the combination of connection and actuation mechanisms determine the possible positions a module can occupy in physical space, relative to neighbor modules. This gives rise to the major division within SR systems, lattice-based versus chain-based systems. In lattice-based systems, modules move among discrete positions, as if embedded in a lattice. Chain-based systems, however, attach together using hinge-like joints and permit snake-type configurations that connect to form shapes such as legged walkers and tank treads. Another class of modular systems cannot self-reconfigure, but can reconfigure with outside intervention. This class is called manually reconfiguring systems.
Cell Structured Robot (CEBOT) was the first proposed self-reconfiguring robot as an implementation of a Dynamically Reconfigurable Robotic System (DRRS). The DRRS definition parallels our current conception of self-reconfiguring robots - the system is made up of robotic modules (cells) which can attach and detach from each other autonomously to optimize their structure for a given task. The idea is directly inspired by biological concepts and this is reacted in the chosen terminology. It is interesting that this proposed SR robot is heterogeneous: cells have a specialized mechanical function and fall into one of three “levels”. Level one cells are joints (bending, rotation, sliding) or mobile cells (wheels or legs). Linkage cells are part of Level two, and Level three contains end-effectors such as special tools. Communication and computation are assumed for all cells.
CEBOT is the physical instantiation of DRRS. Various versions range from reconfigurable modules to “Mark-V,” which more closely resembles a mobile robot team.
Modules can connect to each other in various ways, and the combination of connection and actuation mechanisms determine the possible positions a module can occupy in physical space, relative to neighbor modules. This gives rise to the major division within SR systems, lattice-based versus chain-based systems. In lattice-based systems, modules move among discrete positions, as if embedded in a lattice. Chain-based systems, however, attach together using hinge-like joints and permit snake-type configurations that connect to form shapes such as legged walkers and tank treads. Another class of modular systems cannot self-reconfigure, but can reconfigure with outside intervention. This class is called manually reconfiguring systems.
Cell Structured Robot (CEBOT) was the first proposed self-reconfiguring robot as an implementation of a Dynamically Reconfigurable Robotic System (DRRS). The DRRS definition parallels our current conception of self-reconfiguring robots - the system is made up of robotic modules (cells) which can attach and detach from each other autonomously to optimize their structure for a given task. The idea is directly inspired by biological concepts and this is reacted in the chosen terminology. It is interesting that this proposed SR robot is heterogeneous: cells have a specialized mechanical function and fall into one of three “levels”. Level one cells are joints (bending, rotation, sliding) or mobile cells (wheels or legs). Linkage cells are part of Level two, and Level three contains end-effectors such as special tools. Communication and computation are assumed for all cells.
CEBOT is the physical instantiation of DRRS. Various versions range from reconfigurable modules to “Mark-V,” which more closely resembles a mobile robot team.
Heterogeneous Self-Reconfiguring Robotics
Self-reconfiguring (SR) robots are robots which can change shape to match the task at hand. These robots comprise many discrete modules, often all identical, with simple functionality such as connecting to neighbors, limited actuation, computation, communication and power. Orchestrating the behavior of the individual modules allows the robot to approximate, and reconfigure between, arbitrary shapes.
This shape-changing ability allows SR robots to respond to unpredictable environments better than fixed architecture robots. Common samples of reconfigure ability in action include transforming between snake shapes for moving through holes and legged locomotion for traversing rough terrain, and using reconfiguration for locomotion. SR robots also show promise for a high degree of fault tolerance since modules are generally interchangeable. The robot can self-repair by replacing the broken unit with a spare stored in its structure if one module fails. When all modules are the same, the system is known as homogeneous.
This design difficulty promotes fault-tolerance and versatility. However, a homogeneous system has limitations; all resources that may be required must be built into the basic module. We would like to relax the assumption that all modules are identical and investigate heterogeneous systems, where several classes of modules work together in a single robot. The heterogeneous systems can retain the advantages of their homogeneous counterparts while offering increased capabilities. The benefit would be a robot that can match not only structure to task by changing physical configuration, but also capability to task by using specialized components.
The future consideration application in which exploration tasks are carried out by SR robots. When necessary, the robot reconfigures into a legged walker to move across rough terrain or rubble, or transforms into a snake shape for moving through small holes. The robot can take advantage of smooth terrain as well by deploying a special module type containing wheels for fast, efficient locomotion. A variety of sensors are onboard, contained as modules within the structure of the robot.
This shape-changing ability allows SR robots to respond to unpredictable environments better than fixed architecture robots. Common samples of reconfigure ability in action include transforming between snake shapes for moving through holes and legged locomotion for traversing rough terrain, and using reconfiguration for locomotion. SR robots also show promise for a high degree of fault tolerance since modules are generally interchangeable. The robot can self-repair by replacing the broken unit with a spare stored in its structure if one module fails. When all modules are the same, the system is known as homogeneous.
This design difficulty promotes fault-tolerance and versatility. However, a homogeneous system has limitations; all resources that may be required must be built into the basic module. We would like to relax the assumption that all modules are identical and investigate heterogeneous systems, where several classes of modules work together in a single robot. The heterogeneous systems can retain the advantages of their homogeneous counterparts while offering increased capabilities. The benefit would be a robot that can match not only structure to task by changing physical configuration, but also capability to task by using specialized components.
The future consideration application in which exploration tasks are carried out by SR robots. When necessary, the robot reconfigures into a legged walker to move across rough terrain or rubble, or transforms into a snake shape for moving through small holes. The robot can take advantage of smooth terrain as well by deploying a special module type containing wheels for fast, efficient locomotion. A variety of sensors are onboard, contained as modules within the structure of the robot.
Subscribe to:
Posts (Atom)
