Dexterous control, Intelligent is key to the success of any programmable robot, whether it is an arm, automatically guided vehicle, or dexterous hand. While robotic intelligence is generally associated with processor-driven motor control, many biological systems, including human hands, integrate some degree of specialized reflex control independent of explicit motor-control signals from the brain. Actually, the BarrettHand combines programmable microprocessor intelligence and reflexive mechanical intelligence for a high degree of practical dexterity in real-world applications.
Base on the definition, neither the BarrettHand nor your hand is dexterous. Basically, their superior versatility challenges the definition itself. If the BarrettHand is followed by the strict definition for dexterity, it would require between eight and 16 motors, making it far too complex, bulky, and unreliable for any practical application outside the mathematical analysis of hand dexterity. But, by exploiting four intelligent, joint coupling mechanisms, the almost-dexterous BarrettHand needs only four servomotors. In some examples reflex control is even better than deliberate control. Two examples based on your own body illustrate this point. Accidentally suppose your hand touches a dangerously hot surface. It starts retracting itself instantly, relying on local reflex to override any ongoing cognitive commands. Your hand might burn when waiting for the sensations of pain to travel from your hand to your brain via relatively slow nerve fibers and then for your brain, through the same slow nerve fibers, to command your arm, wrist, and finger muscles to retract.
As the second example, let’s move the outer joint of your index finger without moving the adjacent joint on the same finger. You cannot shift these joints independently because the design of your hand is optimized for grasping. Your tendons and muscles are as lightweight and streamlined as possible without forfeiting functionality. The BarrettHand design recognizes that intelligent control of functional dexterity requires the integration of microprocessor and mechanical intelligence.
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
Gripper legacy of Robotics
Nowadays robotic part handling and assembling is done with grippers. If surface conditions offer, electromagnets and vacuum suction can also be used, for example in handling automobile windshields and body panels. As part sizes start to exceed the order of 100gms, a gripper’s jaws are custom shaped to ensure a secure hold. As the durable of handling mainstay and assembly, these tools have changed little since the beginning of robotics three decades ago. Grippers acts as simple pincers, have two or three unarticulated fingers, called “jaw”. Well organized catalog are available from manufacturers that guide the integrator or customer in tally various gripper components (except naturally for the custom jaw shape) to the task and part parameters.
The sizes of Payload range from grams for tiny pneumatic grippers to 100+ kilograms for massive hydraulic grippers. Typically the power source is hydraulic or pneumatic with simple on/off valve control switching between full-open and full-close states. The jaws usually move 1cm from full-open to full-close. The hand has two or three fingers, called “jaws”. The jaw part that connects the target part is made of a removable and machinably soft steel or aluminum, called a “soft jaw”. According to the unique circumstances, an expert tool designer determines the custom shapes to be machined into the rectangular soft-jaw pieces, The soft-jaw sets are attached to their respective gripper bodies and tested once machined to shape. This process can bring any number of iterations and adjustments until the system works properly. Tool designers redo the entire process each time a new shape is introduced. As consumers demand more variety of product choices and ever more frequent product introductions, the need for flexible automation has never been greater. However, the robotics industry over the past few years has followed the example of the automatic tool exchange technique used to exchange CNCmill cutting tools rather than make grippers more versatile.
The sizes of Payload range from grams for tiny pneumatic grippers to 100+ kilograms for massive hydraulic grippers. Typically the power source is hydraulic or pneumatic with simple on/off valve control switching between full-open and full-close states. The jaws usually move 1cm from full-open to full-close. The hand has two or three fingers, called “jaws”. The jaw part that connects the target part is made of a removable and machinably soft steel or aluminum, called a “soft jaw”. According to the unique circumstances, an expert tool designer determines the custom shapes to be machined into the rectangular soft-jaw pieces, The soft-jaw sets are attached to their respective gripper bodies and tested once machined to shape. This process can bring any number of iterations and adjustments until the system works properly. Tool designers redo the entire process each time a new shape is introduced. As consumers demand more variety of product choices and ever more frequent product introductions, the need for flexible automation has never been greater. However, the robotics industry over the past few years has followed the example of the automatic tool exchange technique used to exchange CNCmill cutting tools rather than make grippers more versatile.
Grasping Robotic of Barret’s Grasper
This article introduces a new approach to material handling, part sorting, and component assembly called “grasping”, in which a single reconfigurable grasper with embedded intelligence replaces an entire bank of unique, fixed-shape grippers and tool changers. We have to explore what is wrong with robotics today to appreciate the motivations that guided the design of Barrett’s grasper, the enormous potential for robotics in the future, and the dead-end legacy of gripper solutions.
Programmable flexibility is needed along the entire length of the robot, from its base, all the way to the target work piece for the benefits of a robotic solution to be realized. An arm of robot enables programmable flexibility from the base only up to the tool plate, a few centimeters short of the work piece target. But these last some centimeters of a robot have to adapt to the complexities of securing a new object on each robot cycle, capabilities where embedded intelligence and software excel. Look like the weakest link in a chain of serial, an inflexible gripper limits the productivity of the entire robot work cell.
Grippers have individually-customized, but fixed jaw shapes. The customization process of trial-and-error is design intensive, generally drives cost and schedule, and is difficult to scope in advance. Generally, each anticipated variation in orientation, shape, and robot approach angle requires another custom-but-fixed gripper, a place to store the additional gripper, and a mechanism to exchange grippers. An incremental improvement or unanticipated variation is simply not allowable.
For a flexibility high degree of tasks requiring such as handling variably shaped payloads presented in multiple orientations, a grasper is more secure, quicker to install, and more cost effective than an entire bank of custom-machined grippers with tool changers and storage racks.
Just one or two spare graspers can serve as emergency backups for several work cells, whereas one or two spare grippers are required for each gripper variation – potentially dozens per work cell for uninterrupted operation. And, it’s catastrophic if both backups of gripper fail in a gripper system, since it may be days before replacements can be identified, shipped, custom shaped from scratch, and physically replaced to bring the affected line back into operation. Since graspers are physically similar, they are always available in unlimited quantity, with all customization provided instantly in software.
Programmable flexibility is needed along the entire length of the robot, from its base, all the way to the target work piece for the benefits of a robotic solution to be realized. An arm of robot enables programmable flexibility from the base only up to the tool plate, a few centimeters short of the work piece target. But these last some centimeters of a robot have to adapt to the complexities of securing a new object on each robot cycle, capabilities where embedded intelligence and software excel. Look like the weakest link in a chain of serial, an inflexible gripper limits the productivity of the entire robot work cell.
Grippers have individually-customized, but fixed jaw shapes. The customization process of trial-and-error is design intensive, generally drives cost and schedule, and is difficult to scope in advance. Generally, each anticipated variation in orientation, shape, and robot approach angle requires another custom-but-fixed gripper, a place to store the additional gripper, and a mechanism to exchange grippers. An incremental improvement or unanticipated variation is simply not allowable.
For a flexibility high degree of tasks requiring such as handling variably shaped payloads presented in multiple orientations, a grasper is more secure, quicker to install, and more cost effective than an entire bank of custom-machined grippers with tool changers and storage racks.
Just one or two spare graspers can serve as emergency backups for several work cells, whereas one or two spare grippers are required for each gripper variation – potentially dozens per work cell for uninterrupted operation. And, it’s catastrophic if both backups of gripper fail in a gripper system, since it may be days before replacements can be identified, shipped, custom shaped from scratch, and physically replaced to bring the affected line back into operation. Since graspers are physically similar, they are always available in unlimited quantity, with all customization provided instantly in software.
Self-Reconfiguring Robots Modules Algorithm
The next step is to investigate the use of reconfiguration in other algorithmic applications after the basic reconfiguration problem is solved. One such class of algorithmic questions deals with resource utilization.
Heterogeneous systems allow specialized modules for communications, mobility, power, computation, or other resources. How these resources should best be distributed for various tasks is an interesting problem. For example, in a manipulation task it may be desirable to move a dedicated power module close to the task through reconfiguration. Another example is sensor deployment. Sensor modules should be carried in the volume of the robot for locomotion, and deployed to the surface for use. A related task would be to store wheel modules in the body of a legged configuration, and to deploy the wheels when wheeled locomotion was possible. The application-level question is how to best use this capability, assuming a solution to the problem of reconfiguration with uniquely identified modules. Specifically, the research issue is to determine a target configuration that optimizes placement of power, sensor, or other specialized modules to best suit the task.
SR modules are used another application involves the problem of constructing rigid structures. Often a SR robot requires structural rigidity, but it is difficult to construct connectors with desirable connection and disconnection properties that can withstand much torque. Power and weight available to a module are both severely limited, so connectors must use small efficient actuators. The result is that current connectors have serious problems with rigidity. A line of Crystal modules, for example, can deform to a great degree.
Any algorithms we design should be implemented and simulated in software. The challenge for heterogeneous systems is to build simulators to represent the varieties of modules. In hardware, building a heterogeneous system by adding sensors or communication to a homogeneous system is an easy strategy. It would also be interesting to construct modules of different shapes. Demonstrating general reconfiguration in hardware remains a significant goal. Overall, the research goal here is to build a suitable software simulator to test our algorithms, and to perform hardware experiments where possible.
Heterogeneous systems allow specialized modules for communications, mobility, power, computation, or other resources. How these resources should best be distributed for various tasks is an interesting problem. For example, in a manipulation task it may be desirable to move a dedicated power module close to the task through reconfiguration. Another example is sensor deployment. Sensor modules should be carried in the volume of the robot for locomotion, and deployed to the surface for use. A related task would be to store wheel modules in the body of a legged configuration, and to deploy the wheels when wheeled locomotion was possible. The application-level question is how to best use this capability, assuming a solution to the problem of reconfiguration with uniquely identified modules. Specifically, the research issue is to determine a target configuration that optimizes placement of power, sensor, or other specialized modules to best suit the task.
SR modules are used another application involves the problem of constructing rigid structures. Often a SR robot requires structural rigidity, but it is difficult to construct connectors with desirable connection and disconnection properties that can withstand much torque. Power and weight available to a module are both severely limited, so connectors must use small efficient actuators. The result is that current connectors have serious problems with rigidity. A line of Crystal modules, for example, can deform to a great degree.
Any algorithms we design should be implemented and simulated in software. The challenge for heterogeneous systems is to build simulators to represent the varieties of modules. In hardware, building a heterogeneous system by adding sensors or communication to a homogeneous system is an easy strategy. It would also be interesting to construct modules of different shapes. Demonstrating general reconfiguration in hardware remains a significant goal. Overall, the research goal here is to build a suitable software simulator to test our algorithms, and to perform hardware experiments where possible.
SCARA Robot Modeling and Trajectory Generation
FORWARD AND INVERSE KINEMATICS
For the case of simple robotics structures such as the one used in this Lab, it is possible to find the inverse kinematics model by only merely geometrical reasoning. That is what is implemented in InverseKinematicsUsingGeometry.m function. Use the InverseKinematics.m function so that no one of the robot joints leaves the robot workspace during the movement execution. Indication: use the possibility to choose what solution (Q1 (low elbow) or Q2 (high elbow)) to assign to the robot final position.
FORWARD AND INVERSE INSTANTANEOUS KINEMATICS
Knowing the Forward Instantaneous Kinematics Model (FIKM) of the SCARA robot given by ForwardInstantaneousKinematics.m function, program the Inverse Instantaneous Kinematics Model (IIKM) InverseInstantaneousKinematics.m. While interfacing your IIKM to the Simulink diagram, simulate a rectilinear displacement with constant speed of the end-effector according to its x axis (use the provided interface to observe the result).
It is imperative to manage correctly the singular robot configurations in order to warn all erratic movement of the robot. What are the singular positions of the studied robot? Use this knowledge so that the robot avoids these singular configurations. Indications:
• The only program to modify is the one where you defined the robot IIKM,
• For the singularities in the robot workspace limits, one can impose software stops of the robot angles evolutions in order to stop rightly before the configuration “completely tense arm” or “completely folded arm”.
TRAJECTORY GENERATION (WORKING AND JOINT SPACE CONFIGURATION)
Basing on the SetPointTrajectory.m function, give the end-effector a circular trajectory (with ray = 2 and center C=(0, 7.5)).
Basing on the Order1Interpolation.m file, write a 5 degrees interpolator generator for the SCARA robot between 2 points of the joint space qi=[100° 100°] to qf=[6° 60°].
ROBOT ARM CONTROL
This part of the Lab introduces the dynamical model of the SCARA robot in order to address some problematic linked to robot arm control. You will find below the description of a set of programs attached to those given previously.
ForwardDynamicalModel.m
Defines the acceleration of the robot joints according to the torques applied by its actuators.
SimulinkLabLibrary.mdl
Contains Simulink blocks to be used directly in your Lab.
SimulinkRobotControlWithDyMo.mdl
Simulink model that permits to use a PID controller to control the robot in the working space.
For the case of simple robotics structures such as the one used in this Lab, it is possible to find the inverse kinematics model by only merely geometrical reasoning. That is what is implemented in InverseKinematicsUsingGeometry.m function. Use the InverseKinematics.m function so that no one of the robot joints leaves the robot workspace during the movement execution. Indication: use the possibility to choose what solution (Q1 (low elbow) or Q2 (high elbow)) to assign to the robot final position.
FORWARD AND INVERSE INSTANTANEOUS KINEMATICS
Knowing the Forward Instantaneous Kinematics Model (FIKM) of the SCARA robot given by ForwardInstantaneousKinematics.m function, program the Inverse Instantaneous Kinematics Model (IIKM) InverseInstantaneousKinematics.m. While interfacing your IIKM to the Simulink diagram, simulate a rectilinear displacement with constant speed of the end-effector according to its x axis (use the provided interface to observe the result).
It is imperative to manage correctly the singular robot configurations in order to warn all erratic movement of the robot. What are the singular positions of the studied robot? Use this knowledge so that the robot avoids these singular configurations. Indications:
• The only program to modify is the one where you defined the robot IIKM,
• For the singularities in the robot workspace limits, one can impose software stops of the robot angles evolutions in order to stop rightly before the configuration “completely tense arm” or “completely folded arm”.
TRAJECTORY GENERATION (WORKING AND JOINT SPACE CONFIGURATION)
Basing on the SetPointTrajectory.m function, give the end-effector a circular trajectory (with ray = 2 and center C=(0, 7.5)).
Basing on the Order1Interpolation.m file, write a 5 degrees interpolator generator for the SCARA robot between 2 points of the joint space qi=[100° 100°] to qf=[6° 60°].
ROBOT ARM CONTROL
This part of the Lab introduces the dynamical model of the SCARA robot in order to address some problematic linked to robot arm control. You will find below the description of a set of programs attached to those given previously.
ForwardDynamicalModel.m
Defines the acceleration of the robot joints according to the torques applied by its actuators.
SimulinkLabLibrary.mdl
Contains Simulink blocks to be used directly in your Lab.
SimulinkRobotControlWithDyMo.mdl
Simulink model that permits to use a PID controller to control the robot in the working space.
Expected Contributions Self-Reconfiguring Robots
Like homogeneous systems, heterogeneous SR systems promise versatility and usefulness superior to fixed architecture robots through their ability to match structure to task. In addition, heterogeneous systems further this goal with their ability to match capability to task. The original vision of reconfigurable systems was inherently heterogeneous, and during the subsequent fifteen years researchers have accrued much knowledge of homogeneous systems. In this thesis, we propose to widen this understanding into the realm of heterogeneous systems. We plan to address fundamental algorithmic issues and demonstrate solutions in simulation and hardware where possible. The results of this work should shed light on the relative complex it of hardware versus software design in SR systems and lead to an algorithmic basis for heterogeneous
self-reconfiguring robots.
We have proposed a framework for categorizing SR modules, and we have chosen a simple theoretical module on which to build reconfiguration algorithms. We will attempt to prove lower bounds for the basic problem and extend the results to systems with greater heterogeneity. There are other algorithmic issues we will address which are enabled by previous reconfiguration solutions, and by our previous work with non-actuated modules, path planning, Goal Recognition, and distributed locomotion.
Finally, we propose to construct a software simulator with which to demonstrate our algorithms. This simulator should be suitable for further use by other researchers in the area. We also hope to perform hardware experiments where available.
The main expected contribution of the proposal is an algorithmic basis for heterogeneous SR systems. This contribution is supported by the following items:
• Framework for heterogeneous modules
• Reconfiguration in 2D and 3D with Sliding Cube model, with arbitrary size ratios
• Reconfiguration with non-actuated modules
• Complexity analysis for reconfiguration
• Applications involving resource trade-offs and optimization
• Implementation in simulation
• Hardware experimentation
self-reconfiguring robots.
We have proposed a framework for categorizing SR modules, and we have chosen a simple theoretical module on which to build reconfiguration algorithms. We will attempt to prove lower bounds for the basic problem and extend the results to systems with greater heterogeneity. There are other algorithmic issues we will address which are enabled by previous reconfiguration solutions, and by our previous work with non-actuated modules, path planning, Goal Recognition, and distributed locomotion.
Finally, we propose to construct a software simulator with which to demonstrate our algorithms. This simulator should be suitable for further use by other researchers in the area. We also hope to perform hardware experiments where available.
The main expected contribution of the proposal is an algorithmic basis for heterogeneous SR systems. This contribution is supported by the following items:
• Framework for heterogeneous modules
• Reconfiguration in 2D and 3D with Sliding Cube model, with arbitrary size ratios
• Reconfiguration with non-actuated modules
• Complexity analysis for reconfiguration
• Applications involving resource trade-offs and optimization
• Implementation in simulation
• Hardware experimentation
Reconfiguration for Robot Locomotion
Reconfiguration is generally discussed in terms of task-specific shape transformation, but it can also be used for locomotion. We have developed a distributed locomotion algorithm for unit-compressible robots using inchworm-like motion, and implemented this algorithm in hardware on the Crystal system. We also performed extensive experimentation; the algorithm ran for over 75 hours in total at the SIGGRAPH and AAAI conferences. The algorithm and experiments are described in this section.
Inchworm locomotion uses friction with the ground to move a group of unit-compressible modules forward. The algorithm is based on a set of rules that test the module’s relative geometry and generate expansions and contractions as well as messages that modules send to their neighbors. When a module receives a message from a neighbor indicating a change of state, it tests the neighborhood against all the rules, and if any rule applies, executes the commands associated with the rule. The algorithm is designed to mimic inchworm-like locomotion: compressions are created and propagated from the back of the group to the front, producing overall motion.
The message types it can send and receive, and the procedures that are called from the message handlers (including the rules of the algorithm). The “tail” module contracts first, which signals its forward neighbor to contract. Each module expands after contraction, so that the contraction propagates through the robot. When the contraction has reached the front of the group, the group will have moved half a unit forward (in theory; empirical results show nearly optimal distance-per-step for chains of five or more units.
Depending on context, once the leader of the group has contracted and expanded, it can then send a message back to the tail to initiate another step. We implemented this algorithm and performed experiments with various shapes. The experiments successfully demonstrated reliable locomotion in the configurations we tested. See Butler, Fitch and Rus for further discussion. This locomotion gait is significant first in that it exemplifies the style of distributed, scalable algorithms we wish to develop and implement in proposed work.
Inchworm locomotion uses friction with the ground to move a group of unit-compressible modules forward. The algorithm is based on a set of rules that test the module’s relative geometry and generate expansions and contractions as well as messages that modules send to their neighbors. When a module receives a message from a neighbor indicating a change of state, it tests the neighborhood against all the rules, and if any rule applies, executes the commands associated with the rule. The algorithm is designed to mimic inchworm-like locomotion: compressions are created and propagated from the back of the group to the front, producing overall motion.
The message types it can send and receive, and the procedures that are called from the message handlers (including the rules of the algorithm). The “tail” module contracts first, which signals its forward neighbor to contract. Each module expands after contraction, so that the contraction propagates through the robot. When the contraction has reached the front of the group, the group will have moved half a unit forward (in theory; empirical results show nearly optimal distance-per-step for chains of five or more units.
Depending on context, once the leader of the group has contracted and expanded, it can then send a message back to the tail to initiate another step. We implemented this algorithm and performed experiments with various shapes. The experiments successfully demonstrated reliable locomotion in the configurations we tested. See Butler, Fitch and Rus for further discussion. This locomotion gait is significant first in that it exemplifies the style of distributed, scalable algorithms we wish to develop and implement in proposed work.
Subscribe to:
Posts (Atom)
