Actuators
Actuators
Actuators are essential devices in robotics and widely common, particularly for industrial
applications.
Actuators come in various types and sizes, depending on the load associated with factors like
force, torque, speed of operation, precision, accuracy, and power consumption. One of the
prevalent types of actuators is electric motors such as servomotor, stepper motor, and direct
current (DC) motors. A motor allows the robot to control a wheel, a switch, or even an arm.
Robot manufacturers usually use electric actuators since they are fast, efficient, and accurate.
They are easy to control, can achieve high velocities (1000 – 10000 rpm), and have ideal
torque for driving. At the same time, they are very weak or unpleasantly heavy because of
their complexity.
Servo motor is a mechanism based on feedback control. It has a high maximum torque/force
that allows high (de)acceleration. It is robust and has a high bandwidth that provides accurate
and fast control.
Then, we have electromechanical actuators that convert electrical energy into mechanical
energy. Based on the basic principle of magnetism, they come in DC, AC, and stepper motors.
The third option is hydraulic and pneumatic actuators, which use fluid power and
compressed air, respectively. Fluid power refers to the energy that is transmitted via a fluid
under pressure. When pressure is applied to a confined chamber containing a piston, the piston
will exert a force causing a motion. Pneumatic systems deliver the lowest power-to-weight ratio,
while hydraulic systems have the highest power-to-weight ratio. Pneumatic actuators are mostly
used for the opening and closing of grippers.
Hydraulic systems are very stiff and non-compliant, whereas pneumatic systems are
easily compressed and thus are compliant. Notably, stiff systems have a more rapid response to
changing loads and pressures and are more accurate. Although stiffness causes more responsive
and more accurate systems, it also creates a danger if all things are not always perfect.
Hydraulic actuators are very efficient, yet their cost is high.
• Another significant advantage is the possibility of having the actuator, force sensor,
and position sensor contained in a one-piece unit. However, the main problem with
implementing piezoelectric actuators is the small oscillating movements caused by its
expansion and contraction.
Leadthrough Programming
Method Textual Robot
Languages Leadthrough
Programming Method:
Powered
Leadthrough Method
Manual Leadthrough
Method
a) Powered Leadthrough Method:
Teach Method
The logic for the program can be generated either using a menu
based system or simply using a text editor but the main characteristic of
this method is the means by which the robot is taught the positional data.
A teach pendant with controls to drive the robot in a number of different
co-ordinate systems is used to manually drive the robot to the desired
locations.
These locations are then stored with names that can be used
within the robot program. The co-ordinate systems available on a
standard jointed arm robot are :-
JointCo-ordinates
Global Co-ordinates
The tool centre point of the robot can be driven along the X, Y or Z axes of
the robots global axis system. Rotations of the tool around these axes can also be
performed
Tool Co-ordinates
Similar to the global co-ordinate system but the axes of this one are
attached to the tool centre point of the robot and therefore move with it.
This system is especially useful when the tool is near to the workpiece.
Workpiece Co-ordinates
Lead Through
This system of programming was initially popular but has now almost
disappeared. It is still however used by many paint spraying robots. The
robot is programmed by being physically moved through the task by an
operator. This is exceedingly difficult where large robots are being used and
sometimes a smaller version of the robot is u ed for this purpose. Any
hesitations or inaccuracies that are introduced into the progr m c nnot be
edited out easily without reprogramming the whole task. The robot con
roller simply records the joint positions at a fixed time interval and then
plays this back.
Off-line Programming
ROBOTC : Other Languages which we use are C,C++ and C # etc. or their
implementation, like ROBOTC, ROBOTC is an implementation of C language. If
we are designing a simple
Robot, we do not need assembly code, but in complex de igning we need well-
defined codes. ROBOTC is another programming language which is C-based. It is
actually a text based programming language. The commands which we w nt to give
to our Robot, first written on the screen in the form of simple text, now as we know
that Robot is a kind of machine and a machine only understands machine langu ge.
So these commands need to be converted in machine language so that robot can
easily underst nd and do whatever it is instructed to do.
Although commands are given in text form (called as codes) but this
language is very specific about the commands which is provi ed as instruction. If
we do even a minor change in given text it will not accept it command. If the
command which is provided to it is correct it colorizes that text, and we came to
know that the given command in text form is correct (as we have shown in our
example gi en below). Programming done in ROBOTC is very easy to do.
Commands given are very stra ghtforward. Like if we want our robot to switch on
any hardware part, we just have to give code regarding to that action in text form.
Suppose we want robot to turn motor of port, we just have to give command in this
way:
Although program above is not exactly shown in the way in which it should
be written, this is just to provide you a visualization of what we have told you. This
is not written in an appropriate manner.ROBOTC provide advantage of speed, a
Robot programmed in ROBOTC programming supports 45 times more speed than
provided by other programming based on C plus it has a very powerful debugging
feature.
ROBOTICS.NXT :
Real-time systems are slaves to the clock. They achieve the illusion
of smooth behavior by rapidly updating set of control signals many times per
second. For example, to smoothly turn a robot's head to the right, the head must
accelerate, travel at constant velocity for a while, and then decelerate. This is
accomplished by making many small adjustments to the motor torques. Another
example: to get the robot's LEDs to blink repeatedly, they must be turned on for a
certain period of time, then turned off for another length of time, and so forth. To
get them to glow steadily at medium intensity, they must be turned on and off very
rapidly.
The robot's operating system updates the states of all the effectors
(servos, motors, LEDs, etc.) every few milliseconds. Each update is called a
"frame", and can accommodate simultaneous changes to any number of effectors.
On the AIBO, updates occur every 8 milliseconds and frames are buffered four at a
time, so the application must have a new buffer available every 32 milliseconds;
other robots may use different update intervals. In Tekkotsu these buffers of frames
are produced by the MotionManager, whose job is to execute a collection of
simultaneously active MotionCommands (MCs) of various types every few
milliseconds. The results of these MotionCommands are assembled into a buffer
that is passed to the operating system (Aperios for the AIBO, or Linux for other
robots). Suppose we want the robot to blink its LEDs on and off at a rate of once
per second. What we need is a MotionCommand that will calculate new states for
the LEDs each time the MotionManager asks for an update. LedMC, a subclass of
both Motion Command and LedEngine, performs this service. If we create an
instance of LedMC, tell it the frequency at which to blink the LEDs, and add it to
the MotionManager's list of active MCs, then it will do all the work for us. There's
just one catch: our application is running in the Main process, while the
MotionManager runs in a separate Motion process. This is necessary to assure that
potentially lengthy computations taking place in Main don't prevent Motion from
running every few milliseconds. So how can we communicate with our
MotionCommand while at the same time making it available to the Motion
Manager.
Machine Loading
TEXT/REFERENCE BOOKS:
1.Saha, S.K., “Introduction to Robotics, 2nd Edition, McGraw-Hill Higher Education, New Delhi, 2014.
2. Ashitava Ghosal., “Fundamental Concepts and Analysis”, Oxford, New Delhi, 2006.
3. Mikell.P.Groover, Mitchell Weiss, Roger.N.Nagel, Nicholas.G.Odrey, “Industrial Robotics-Technology,
Programming and Applications”, Tata McGraw-Hill Publishing Company Limited, New Delhi, Third
Reprint 2008