Project Scrap

Click here to load reader

  • date post

    08-Apr-2015
  • Category

    Documents

  • view

    143
  • download

    5

Embed Size (px)

Transcript of Project Scrap

AUTOMATIC SCRAP COLLECTING ROBOTThe rules basically went as this:o o o o o o

gather and retrieve objects of unknown size/weight battery power is severely limited robot can be remote controlled allowable robot height/length/width limited further objects gained you more points time limit of 3 minutes

Specifications The robot used one HS-311 servo for the actuated storage bucket, one modifiedHS-805BB for the 1 DOF robot arm, one servo for the robot gripper end-effector, and two modified servos for the differential drive train.

The bucket was built from bended aluminum sheet metal, and the frame was both milled and CNCed out from aluminum raw material. Specially shaped foam was used inside the bucket to keep the objects inside from rolling out while wall climbing.

1) The wheels on each side were linked together by a timing belt, for tank style driving. 2) Rubberband was used as belt tensioner. 3) The four wheels were custom CNC machined. 4) Conveyor belt material was glued onto the wheels and grippers for its high friction properties. 5) RC reciever antenna, wrapped so as to not tangle Control, and the Driver The remote control was a Hitec Laser 6 (has 6 channels), each channel controlled each servo individually. The agility of a remote control robot is very much a function of driver skill. If you ever have a remote control robot contest, driver skill can significantly affect robot performance. Practice practice practice. Know exactly how your robot will perform. Practice in realistic settings, too. We went as far as to reconstruct the test course ourselves, timing everything the robot did for speed optimization, and pushing the limits to see what the robot can do. In the video I was operating 5 servos simultaneously with two hands on the remote, a skill that took many many hours of practice to do. But it all paid off . . . An image of a prototype version climbing a wall in our recreated test course:

You probably did not gather this from the video, but the arm was used as a balancing weight shift as it climbed the wall - not just a lifting mechanism. The claws also had to be opened up during the climb, too, so as to not break. This early plastic-made prototype version attempted to climb the wall before we learned about the weight shift feature of the arm. Embarassingly, the basket was lowered accidently and the bot got stuck on its way over. The gripper on this version was made from nylon, and broke during the climb.

Difficulties There were two main difficulties. The first is that the conveyor belt material, in combination with tank style driving friction issues, made turning on carpeting very difficult. At the end of the video you will notice the robot doing weird dancing like motions as it turns around.

This is driver skill attempting to compensate for this problem. The other major problem was arm torque. A lot of effort was put into making the arm very light yet strong enough to support the weight of the robot while wall climbing. If you plan to make one of your own, make sure you do themoment arm calculations first to ensure it is strong enough. We had to gear down the servo with external gears to have just barely enough torque . . . Results So how did we fare? Beating out 12 teams in regionals, the team (four of us) made it to nationals in California where we placed 7th (out of 14). Competition was really impressive and I wish I had videos to show it . . . The SolidWorks CAD file of this robot is available for download (7.1mb). If you use the CAD (or any part of it) for your robot, please give credit and link back to this page.

CONSTRUCTION OF ARM:Mobile Manipulators A moving robot with a robot arm is a sub-class of robotic arms. They work just like other robotic arms, but the DOF of the vehicle is added to the DOF of the arm. If say you have a differential drive robot (2 DOF) with a robot arm (5 DOF) attached (see yellow robot below), that would give the robot arm a total sum of 7 DOF. What do you think the workspace on this type of robot would be?

Force Calculations of Joints This is where this tutorial starts getting heavy with math. Before even continuing, I strongly recommend you read the mechanical engineering tutorials for statics anddynamics. This will give you a fundamental understanding of moment armcalculations. The point of doing force calculations is for motor selection. You must make sure that the motor you choose can not only support the weight of the robot arm, but also what the robot arm will carry (the blue ball in the image below). The first step is to label your FBD, with the robot arm stretched out to its maximum length.

Choose these parameters:o o o o

weight of each linkage weight of each joint weight of object to lift length of each linkage

Next you do a moment arm calculation, multiplying downward force times the linkage lengths. This calculation must be done for each lifting actuator. This particular design has just two DOF that requires lifting, and the center of mass of each linkage is assumed to be Length/2. Torque About Joint 1: M1 = L1/2 * W1 + L1 * W4 + (L1 + L2/2) * W2 + (L1 + L3) * W3 Torque About Joint 2: M2 = L2/2 * W2 + L3 * W3

As you can see, for each DOF you add the math gets more complicated, and the joint weights get heavier. You will also see that shorter arm lengths allow for smaller torque requirements.

Too lazy to calculate forces and torques yourself? Try my robot arm calculatorto do the math for you.

Forward Kinematics Forward kinematics is the method for determining the orientation and position of the end effector, given the joint angles and link lengths of the robot arm. To calculate forward kinematics, all you need is highschool trig and algebra. For our robot arm example, here we calculate end effector location with given joint angles and link lengths. To make visualization easier for you, I drew blue triangles and labeled the angles.

Assume that the base is located at x=0 and y=0. The first step would be to locate x and y of each joint. Joint 0 (with x and y at base equaling 0): x0 = 0 y0 = L0 Joint 1 (with x and y at J1 equaling 0):

cos(psi) = x1/L1 => x1 = L1*cos(psi) sin(psi) = y1/L1 => y1 = L1*sin(psi) Joint 2 (with x and y at J2 equaling 0): sin(theta) = x2/L2 => x2 = L2*sin(theta) cos(theta) = y2/L2 => y2 = L2*cos(theta) End Effector Location (make sure your signs are correct): x0 + x1 + x2, or 0 + L1*cos(psi) + L2*sin(theta) y0 + y1 + y2, or L0 + L1*sin(psi) + L2*cos(theta) z equals alpha, in cylindrical coordinates The angle of the end effector, in this example, is equal to theta + psi. Too lazy to calculate forward kinematics yourself? Check out my Robot Arm Designer v1 in excel. Inverse Kinematics Inverse kinematics is the opposite of forward kinematics. This is when you have a desired end effector position, but need to know the joint angles required to achieve it. The robot sees a kitten and wants to grab it, what angles should each joint go to? Although way more useful than forward kinematics, this calculation is much more complicated too. As such, I will not show you how to derive the equation based on your robot arm configuration. Instead, I will just give you the equations for our specific robot design: psi = arccos((x^2 + y^2 - L1^2 - L2^2) / (2 * L1 * L2)) theta = arcsin((y * (L1 + L2 * c2) - x * L2 * s2) / (x^2 + y^2)) where c2 = (x^2 + y^2 - L1^2 - L2^2) / (2 * L1 * L2); and s2 = sqrt(1 - c2^2); So what makes inverse kinematics so hard? Well, other than the fact that it involvesnon-linear simultaneous equations, there are other reasons too. First, there is the very likely possibility of multiple, sometimes infinite, number of solutions (as shown below). How would your arm choose

which is optimal, based on torques, previous arm position, gripping angle, etc.?

There is the possibility of zero solutions. Maybe the location is outside the workspace, or maybe the point within the workspace must be gripped at an impossible angle. Singularities, a place of infinite acceleration, can blow up equations and/or leave motors lagging behind (motors cant achieve infinite acceleration). And lastly, exponential equations take forever to calculate on a microcontroller. No point in having advanced equations on a processor that cant keep up. Too lazy to calculate inverse kinematics yourself? Check out my Robot Arm Designer v1 in excel. Motion Planning Motion planning on a robot arm is fairly complex so I will just give you the basics.

Suppose your robot arm has objects within its workspace, how does the arm move through the workspace to reach a certain point? To do this, assume your robot arm is just a simple mobile robot navigating in 3D space. The end effector will traverse the space just like a mobile robot, except now it must also make sure the other joints and links do not collide with anything too. This is extremely difficult to do . . . What if you want your robot end effector to draw straight lines with a pencil? Getting it to go from point A to point B in a straight line is relatively simple to solve. What your robot should do, by using inverse kinematics, is go to many points between point A and point B. The final motion will come out as a smooth straight line. You can not only do this method with straight lines, but curved ones too. On expensive professional robotic arms all you need to do is program two points, and tell the robot how to go between the two points (straight line, fast as possible, etc.). For further reading, you could use the wavefront algorithm to plan this two point trajectory. Velocity (and more Motion Planning) Calculating end effector velocity is mathematically complex, so I will go only into the basics. The simplest way to do it is assume your robot arm (held straight out) is a rotating wheel of L diameter. The joint rotates at Y rpm, so therefore the velocity is Velocity of end effector on straight arm = 2 * pi * radius * rpm However the end effector does not just rotate about the base, but can go in many directions. The end effector can follow a straight line, or curve, etc. With robot arms, the quickest way between two points is often not a straight line. If two joints have two different motors, or carry different loads, then max velocity can vary between them. When you tell the end effector to go from one point to the next, you have two decisions. Have it follow a straight line between both points, or tell all the joints to go as fast as possible - leaving the end effector to possibly swing wildly between those points. In the image below the end effector of the robot arm is moving from the blue point to the red point. In the top example, the end effector travels a straight line. This is the only possible motion this arm can perform to

travel a straight line. In the bottom example, the arm is told to get to the red point as fast as possible. Given many different trajectories, the arm goes the method that allows the joints to rotate the fastest.

Which method is better? There are many deciding factors. Usually you want straight lines when the object the arm moves is really heavy, as it requires the momentum change for movement (momentum = mass * velocity). But for maximum speed (perhaps the arm isn't carrying anything, or just light objects) you would want maximum joint speeds. Now suppose you want your robot arm to operate at a certain rotational velocity, how much torque would a joint need? First, lets go back to our FBD:

Now lets suppose you want joint J0 to rotate 180 degrees in under 2 seconds, what torque does the J0 motor need? Well, J0 is not affected by gravity, so all we need to consider is momentum and inertia. Putting this in equation form we get this:

torque = moment_of_inertia * angular_acceleration breaking that equation into sub components we get: torque = (mass * distance^2) * (change_in_angular_velocity / change_in_time) and change_in_angular_velocity = (angular_velocity1)-(angular_velocity0) angular_velocity = change_in_angle / change_in_time Now assuming at start time 0 that angular_velocity0 is zero, we get torque = (mass * distance^2) * (angular_velocity / change_in_time) where distance is defined as the distance from the rotation axis to the center of mass of the arm: center of mass of the arm = distance = 1/2 * (arm_length) (use arm mass) but you also need to account for the object your arm holds: center of mass of the object = distance = arm_length (use object mass) So then calculate torque for both the arm and then again for the object, then add the two torques together for the total: torque(of_object) + torque(of_arm) = torque(for_motor) And of course, if J0 was additionally affected by gravity, add the torque required to lift the arm to the torque required to reach the velocity you need. To avoid doing this by hand, just use the robot arm calculator. But it gets harder . . . the above equation is for rotational motion and not for straight line motions. Look up something called a Jacobian if you enjoy mathematical pain =P

OBSTACLE AVOIDER CONSTRUCTION:The photo below shows my test setup with some IR LED's (dark blue) as a light source and two phototransistors in parallel for the reciever. You could use one of each but I wanted to spread them out to cover a wider area. This setup works like a FritsLDR but with IR. It has a range of about 10-15cm (46 inches) with my hand as the object being detected. I'm only running my LEDs about 20mA. My LEDs are capable of 50mA continuous and some LEDs are capable of 100mA (see "Getting the most from a LED"). I'm using this setup on Junior as a general purpose object advoidance sensor to prevent him backing into anything. I'm getting a good response with less than a volt when my hand is up close and reflecting the IR and over 4.5V with no IR.

To get this to work well with an A/D input it needs to have a much lower impedance (needs to let more current through). You can do this with an opamp but most op-amps like more than 5V and are usually more expensive than my one transistor and three resistors. This is a simple one transistor

amplifier that gives my ADC good resolution. Click on the schematic for a larger picture.

Starting from the left you can see my two IR LEDs with a resistor and transistor in series. The transistor allows the processor to turn the LEDs on or off. This is necessary to tell the difference between the ambiant IR from daylight and indor lighting and the reflected light from the LEDs that indicates the presence of an object. Next are my two phototransistors in parallel with a 1M resistor in series. You could use only one but I wanted to cover a wider area so my transistors will point in slightly different directions. If either one detects IR it will allow more current to flow. Since volts=current x resistance, even a small increase in current will create a reasonable increase in voltage across the 1M resistor. Unfortunately the low input impedance of many AD converters will act like a small resistor in parallel with the 1M resistor and dramatically reduce the output to the processor. This is where our BC549 transistor comes in to save the day. In conjunction with the 1K and 10K resistors it amplifies the signal so that the analog input on your processor gets a nice strong signal. The BC549 is not too critical, just about any general purpose signal transistor should do. My transistor had a hfe of 490 when measured with a multimeter. You should probably have a hfe of at least 200-300.

As you can see my sensor is made from liberal amounts of hotglue. Click image for a bigger picture. This has the advantage that you can flex the leds and transistors outward to cover a larger area. This is Juniors reversing sensor to prevent him reversing into anything and as such will cover a wide area. I will make single Led/Phototransistor sensors for front left and front right. This will allow him to avoid crashing into obstacles when his rangefinder/object tracker is looking elsewhere. Note that the phototransistors are slightly forward of the blue LEDs. This helps stop stray light from the LEDs being detected. Below is the sensor hooked up to Juniors mainboard which has three of my amplifiers built in.

Using a simple test program that turns on the IR LEDs, stores the value of the ADC, turns off the LEDs, reads the ADC again and then subtracts the stored value from the recent value I was getting readings from 6 to 940. This was with the curtains closed and the lights off. When the reading was 6, my hand was about 300mm (1ft) away. With the lights on the values ranged from about 60 to 940 with a value of 60 being with my hand only about 150mm (6inches) away. Considering the max possible resolution with a 10bit ADC is 0 to 1023, I thought 60-960 with the lights on was a very good result. After a comment about using sleeves I repeated these test with heatshrink sleeves on the LEDs and phototransistors. The sleeves actually had a negative effect and reduced the range. After I removed the sleeves I did not get the same reduction in range with the lights on. I don't know if it is because during the first test it was daylight outside and the curtains didn't block it all or if it was the way I held the sensor but the second set of test gave an almost identical range of approximately 300mm (12 inches) reguardless of the lights being on or off. I'll have to try again tomorrow when it is daylight again. It seems my initial test was at fault, maybe the way I held the sensor? This is the single version of the sensor and will cost about half. In the photo you can see the current limiting resistor for the LED. Ignore the value as I had different requirements for Junior. Use the values shown in the schematic. I've joined the positives together so there is only three wires going back to the mainboard. Note that the phototransistor is slightly in front of the LED to prevent stray light from the LED being detected.

Once again I've used hotglue and

heatshrink to make it solid and well insulated.

This is the schematic for the single version. Click on it and the photos for larger images.

Because this sensor only has a single

phototransistor it isn't quite as sensitive. To compensate I've increased the current to the LED to almost 50mA which is the maximum continuous

current allowed. Because the LED is pulsed on and off this is quite safe and could have been increased to 100mA. The problem with pushing a LED to its limits when controlled by a proccesor is that if a fault occurs in the software then the LED could be destroyed. When tested, The readings from the ADC of the picaxe ranged from about 100 - 910 reguardless of background lighting. Despite the slightly reduced resolution due to a single phototransistor the range was about 400mm (16inches). This increased range was due to the increased power to the LED. Make certain your LED and phototransister are parallel to each other for good range. It was asked how wide is the detection area. Using my hand as the object at a distance of aproximately 300mm (12 inches) from the single sensor the detection area was about 150mm (6 inches) wide. The double sensor can detect a wider area if the phototransistors are spread out at different angles. Using my hand sideon to the single sensor the detection area was only about 60-70mm (2-3 inches). This is reasonably narrow due to the lenses in the LEDs and the phototransistors. It should be noted that this is not a linear sensor because the intensity of light from the LEDs is 1 divided by distance squared. In other words, when the object is twice the distance away, the IR from the LEDs is 1/4. As a result, the closer the object, the better the resolution. This would be a useful sensor to fill in for the dead zone of other IR sensors such as the SHARP GP2D12. To prevent interferance, one should be disabled when using the other. As mentioned at the start, I've also experimented with using two of these sensors for a simple object tracker inspired by Mintvelt's "four eyes". This version can't tell the size or distance of an object but can track an object well enough for a robot to recognise a moving object and give chase. Wish I still had a cat, imagine a robot with a waterpistol chasing a cat around the house : I've attached the code used in the video as well as an improved version (V1.7) that eliminated the servo jitter.

This is the latest version of my object tracker as used in SplatBot. I've used 20 IR leds to increase the range. They are limited to 50mA at the moment so that they can't be damaged by faulty code. If I was to push them to their limit then the range could be increased further but they could then be damaged by something like an interupt routine occuring when the LEDs are on.

This is the schematic.

Click on it for a larger picture. I found with all The LEDs on that the sensors were swamped by reflected IR from my hand even at a distance of about 400mm. The circuit works fine and I definitely get a lot more range but I'm going to have to remove the sensors from the board and mount them seperately so that I can adjust their distance relative to each other to optimise tracking and so I can better shield them from ambiant IR. I've experimented with improving and simplifying the detection circuit. This will give you better range.

The MPSA13 is a high gain darlington transistor with a hfe of over 5000. If you get the MPSA14 it has about twice the gain. By adjusting the 500 ohm trimpot you should get much better range than the old circuit.

Micro-Controller USED:A microcontroller is an entire computer manufactured on a single chip. Microcontrollers are usually dedicated devices embedded within an application e.g. as engine controllers in automobiles and as exposure and focus controllers in cameras. In order to serve these applications, they have a high concentration of on-chip facilities such as serial ports, parallel input/output ports, timers, counters, interrupt control, analog-to-digital converters, random access memory, read only

memory, etc. The I/O, memory, and on-chip peripherals of a microcontroller are selected depending on the specifics of the target application. Since microcontrollers are powerful digital processors, the degree of control and programmability they provide significantly enhances the effectiveness of the application. Embedded control applications also distinguish the microcontroller from its relative, the generalpurpose microprocessor. Embedded systems often require real-time operation and multitasking capabilities. Real-time operation refers to the fact that the embedded controller must be able to receive and process the signals from its environment as they are received. Multitasking is the capability to perform many functions in a simultaneous or quasi-simultaneous manner (Yeralan, S. & Emery, 2000, p. 2). Figure 2. Block diagrams of a Microcontroller (microElectronika, 2004) The various components of the MCU shown in Figure 2 are explained below: Random Access Memory (RAM): RAM is used for temporary storage of data during runtime. ROM: ROM is the memory which stores the program to be executed. SFR Registers: Special Function Registers are special elements of RAM. Program Counter: This is the "engine" which starts the program and points to the memory address of the instruction to be executed. Immediately upon its execution, value of counter increments by 1. Development of a Microcontroller Based Robotic Arm 552 Control Logic: As the name implies, it which supervises and controls every aspect of operations within MCU, and it cannot be manipulated. It comprises several parts, the most important ones including: instructions decoder, Arithmetical Logic Unit (ALU) and Accumulator. A/D Converter: A/D stands for analog to digital. They convert analog signals to digital

signals. I/O Ports: To be of any practical use, microcontrollers have ports which are connected to the pins on its case. Every pin can be designated as either input or output to suit user's needs. Oscillator: This is the rhythm section of the MCU. The stable pace provided by this instrument allows harmonious and synchronous functioning of all other parts of MCU. Timers: timers can be used for measuring time between two occurrences and can also behave like a counter. The Watchdog Timer resets the MCU every time it overflows, and the program execution starts anew (much as if the power had just been turned on). Power Supply Circuit: this powers the MCU. (MikroElectronika, 2004). Methodology The method employed in designing and constructing the robotic arm are based on the operational characteristics and features of the microcontrollers, stepper motors, the electronic circuit diagram and most importantly the programming of the microcontroller and stepper motors. Block Diagram The block diagram of our work is as shown in Figure 3. Figure 3. Block diagram CONTROL UNIT [MCU] KEYPAD MOTORS MAGNETIC SENSORS Sensor driver (transistor) Motor driver (transistors) POWER SUPPLY UNIT

Jegede, Awodele, Ajayi, & Miko 553 Circuit Diagram The electronic circuit diagram of the development board is as shown in Figure 4. The connection of the identified components and devices are as shown. The components shown are: the MCU, the LATCH 74LS373, the EPROM 2732, Intel 8255 PIO, diodes, resistors, capacitors, inductors, transistors, and op-amps. This components work together to achieve the set goal of controlling the anthropomorphic-like arrangement of the stepper motor. The microcontroller is the processing device that coordinates all the activities of all the components for proper functioning. Power Supply This is used to power the whole system i.e. the Control Unit, Magnetic Sensing Unit, and the Stepper Motors. The transformer is a 220/12V step down transformer. We used a bridge rectifier to convert the 12V alternating current to direct current. The unregulated output from the filtering circuit is fed into a voltage regulator LM7805 and LM7812. These two are chosen for the design because the LM7805 has an output of +5V which is required to power the Control Unit, and the Magnetic Coil while the LM7812 has an output of +12v which is required to power the Stepper motors. The TIP41 connected to the IC regulators functions as an emitter follower amplifier making sure that at least the required voltage by the Control Unit, the Magnetic Coil and the Stepper Motors produced. MCU 8051 This is the processor. It coordinates the operation of the robotic arm by collecting information from the EPROM, the LATCH, and the PIO; interprets and then execute the instructions. It is the heart of the whole system. LATCH 74LS373

This is a D-type transparent latch. It is an 8 bit register that has 3 state bus driving outputs, full parallel access for loading, and buffer control inputs. It is transparent because when the enable EN(enable) input is high, the output will look exactly like the D input. This latch particularly separates the data and address information from the MCU before sending to the instructed destination. The high-impedance state and increased high logic-level drive provide these registers with the capability of being connected directly to and driving the bus lines in a bus-organized system without need for interface or pull-up components. These latches are particularly attractive for implementing buffer registers, I/O ports, bidirectional bus drivers, and working registers. We are using this latch because there is a need to separate our 8 bit data and 8 bit address information from the common line of the MCU, and send them to the appropriate device(s). 8255 PIO This is a programmable input/output device. It interfaces the connection between the 8051, the LATCH 74LS373, and the EPROM 2732 to external devices such as the stepper motors, (as is our own case) thereby allowing for communication. (EPROM) 2732 EPROM stands for Electrically Programmable Read Only Memory. We made use of this external EPROM specifically because it makes the controller cheaper, allows for longer programs, and because its content can be changed during run time and can also be saved after the power is off. Development of a Microcontroller Based Robotic Arm 554 Figure 4. Control Unit (Digitouch, 2006) The overall diagrammatical layout of the complete circuit diagram of the whole control unit is shown in Figure 4.

Stepper Motor The stepping motor is a motor that is driven and controlled by an electrical pulse train generated by the MCU (or other digital device). Each pulse drives the stepping motor by a fraction of one revolution, called the step angle. Jegede, Awodele, Ajayi, & Miko 555 The Magnetic Sensing Unit The magnetic sensing unit consists of a magnetic coil which can be magnetized simply by the action of the port P1.0 of the 8051. The port 1.0 was made use of because when designated as output, each of the pin can be connected up to four TTL inputs. That is why we have connected the pin 1.0 to the magnetic coil through three TTL logic. The design is such that on the downward movement of the wrist, the 8051 sends an electrical signal to the Darlington pair connected to the magnetic coil. The magnetic sensing unit is powered on by three BC548 Darlington NPN pair transistor, through a diode each and a 5k resistor. The pair amplifies the current and makes the magnetic coil turn into magnet. Then any magnetic material could be picked (by attraction) and then movement continues. The magnetic material can then be dropped at another point when the wrist is made to come down, this also is an action from the 8051 as it withdraws the electrical signal from the coil. Control Circuit This is the control panel of the system as it oversees the operations of the mechanical arm, and the magnetic sensing unit. The MCU 8051 of the control unit acts as the brain of the control panel as it coordinates all the activities of the other devices. When power (+5V) was supplied to the control unit, the MCU started off by loading the program from the EPROM M2732A, interpreted and executed the instruction codes through the various operational principles which had been described

in details in chapter three (session 3.2). The 8051 then sends signal to the stepper motor which moves 9 per step. The stepper motor (M3) at the wrist first moves five times (45) turning the gears to cause a downward movement of the hand. The stepper motor at the shoulder (M2) moves next stepping five times (45) and makes the connected gears to cause the movement of the arm 45 forward. Then the stepper motor at the base(M1) moves either ten times (90) or twenty times (180), depending on the button pressed, causing the whole structure to turn from right to left( or vice versa) through the connected gears. The magnetic coil resting on the hand becomes magnetized immediately the last gear on the hand stops moving. Then, it magnetizes (picks) any magnetic material it can find and then M3 and M2 moves the arm up while M1 moves (rotates the structure) from left to right (or vice versa) and then the 8051 demagnetizes the magnetic coil thereby making the hand to drop the metallic object. Results This work is able to successfully accomplish the defined functionality. A sample robot which can rotate, magnetize an object, lower and raise its arm, by being controlled by the 8051 microcontroller is built successfully. The 8051-development board is soldered and it used the required procedure for the correct operation of the controller. The 8051 development board has been interfaced to the stepper motors such that the anthropomorphic like structure can be controlled from the buttons at the base of the structure (robotic arm). There are four buttons being controlled by the control unit at the base of the arm: ON/OFF: the ON button puts on the system while the OFF button puts off the system START/STOP: the START button starts the movement of the whole arm from its reset

point, while the STOP button takes the arm back to its reset button after completion of its movement. Development of a Microcontroller Based Robotic Arm 556 RIGHT-LEFT/LEFT-RIGHT: when this button is switched to the RIGHTLEFT part it causes movement from right to left, while the LEFT-RIGHT part causes movement from left to right. 180/90: when the button is on 180, it causes a rotation of 180 degree of the base stepper motor, but when put on 90 degrees, it causes rotation of 90 degrees. Conclusion In this paper we have interfaced the robot with different kinds of I/O devices and our method allows for storing more programs to enhance more functionality. From our work, we deduced that in comparison to humans, robots can be much stronger and are therefore able to lift heavier weights and exert larger forces. They can be very precise in their movements, reduce labor costs, improve working conditions, reduce material wastage and improve product quality (Mair, 1988). This is why theyre very important in industries because the overall objective of industrial engineering is productivity (Hicks, 1994, p. 61). Meanwhile, intelligent Control is the discipline that implements Intelligent Machines (IMs) to perform anthropormorphic tasks with minimum supervision and interaction with a human operator. This project can be further enhanced to as a multi-disciplinary project involving electrical and computer engineers to work together to create more complex, intelligent robots controlled by the 8051 micro-controller. References Bejczy, A. K., & Jau, B. M. (1986). Smart hand systems for robotics and teleoperation. Proceedings of the

Sixth CISM-IFToMM Symposium on Theory and Practise of Robots and Manipulators, Hermes Publishing. Engelberger, J. F. (1989). Robotics in service (pp 224-226). Kogan Page. Hall, D. V. (2004). Microprocessors and interfacing, Programming and hardware (pp 278-279). McGraw Hill. Hicks, P. E. (1994). Industrial engineering and management. McGraw-Hill. Mair, G. M. (1988). Industrial robotics. Prentice Hall. microElectronika. (2004). Architecture and programming of 8051 MCU (Chapter 1). Pont, M. J. (2002). Embedded C. Addison-Wesley. Robotics Research Group. (n.d.). Learn More History. Retrieved from http://www.robotics.utexas.edu/rrg/learn_more/history/ Selig, J. M. (1992). Introductory robotics. Prentice Hall. Valavanis, K. P., & Saridis, G. N. (1992). Intelligent robotics. Academic Publishers. Yeralan, S., & Emery, H. (2000). Programming and interfacing the 8051 microcontroller in C and Assembly. Rigel Press.