Here is one of many “leave it for later” projects that I always wanted to finish. Although it is not finished I will show you what I have so far.
Of course is a very easy project! But at the same time is very gratifying; according to the philosophy of this blog, Fast & Simple Projects.
The required material:
-> 1 microcontroller based system (embedded type or not!).
-> 2 Half bridge Drivers (LN298, for instance).
-> 2 DC power supply (battery or charger); one for feeding the microcontroller and another one for feedding the motors.
-> 4 DC motors. But it could be possible that is needed more than one motor per joint, It all depends on the size/weight of the robot parts.
-> 5 endstop sensors.
My basic design for controlling the Robotic Arm Manipulator is shown on the drawing below:
Important: As it is shown in the drawing, the ground reference (GND) of microcontroller and ground reference (GND) of the H-B drivers have to be the same.
Note: I know that a Robot Arm Manipulator should be controlled by rotative encoders (for each motor) in order to close the feedback control loop of the system, but, this will be handled in another post.
The next step is to find the best parts for the “mechanics” that better suits your idea or project:
-> Strong metal parts for robust configuration (like steel); but they are very heavy and this means you’ll need big motors and more power to control the system.
-> Light metal parts (like aluminium parts); this is the best option but keep in mind that aluminium parts are quite expensive.
-> Plastic parts; they’re not robust, but they’re the lightest! and the cheapest! Also they’re are very “modular” and for the fast development projects this will be the best way to build the robot system.
Yes, thats it, I went for the plastic “mechanical” assembly option, and here is the result:
This picture shows the different parts of the robot:
M1 -> double DC motor that rotate the base of the robot (Need a reduction gear to gain power transmission).
M2 -> double DC motor that push the arm towards or backwards (Need a reduction gear to gain power transmission).
M3 -> DC motor that move the gripper up or down (Need a reduction gear to gain power transmission).
Gripper -> DC motor for open and close the Gripper.
The “very ugly” plastic flanges in the base were a temporary solution until I found a wider gear to couple the robot’s base with the rest of the robot arm (shown in the next picture).
The reduction gear coupled on the axis of the motors is very important to gain torque and also for increase accuracy when the motor is rotating. Here are shown the reduction gear used for M1 (the”very ugly” plastic flanges to hold the robot, is solved):
The other hardware installed on the robot is an endstop sensor for each joint (except for the M1 that has two, left & right endstop sensor). The idea is that after playing with robot or after a number of robot moves, the robot’s joints could be located in an unknown position. To restart the robot’s position, many mechatronic systems have a “home” position that is knowm by the system itself with the help of some external sensors (out of the joint, even if we’ve got encoders) so that when the robot reach the “home” position we’re able to perform some kind of reset of the read value of the joint positions.
The basic diagram for the endstop sensors follows as:
Here are some pictures showing where I put the endstop sensors in order to know the left and right stop position for M1 rotations:
The second picture from the image set above shows the left endstop sensor before being reached by M1 rotation and the third picture shows when the left endstop sensor is reached by the M1 rotation.
For the rest of the endstop sensors are quite easy to put them, just think about which is the best “home” position for the robot.
Concerning the gripper, it was a little bit more tricky. Here the pictures showing the endstop sensor for detecting if the gripper is open or closed:
The next step (and the best!) is make your computer able to communicate with our robot. Here is displayed the basic idea abou it:
The PC application could be anything (Serial Console, C++ application, Python code using serial.py, ..) that is able to open a serial port and to receive/send data. And it could look like my Robot’s “Service/Diagnostics User Interface”:
The microcontroller is designed (by code) to receive ASCII characters as commands; depending on the command the robot has to perform several actions. Here is the realtion of “characterrobot action” that I settled:
|A||65||Turn right M1|
|B||66||Turn left M1|
|C||67||Move forward M2|
|D||68||Move Backwards M2|
|E||69||Move up M3|
|F||70||Move down M3|
|I||73||Select speed M1 “FINE”|
|J||74||Select speed M1 “SLOW”|
|K||75||Select speed M1 “MEDIUM”|
|L||76||Select speed M1 “FAST”|
|M||77||Select speed M2 “FINE”|
|N||78||Select speed M2 “SLOW”|
|O||79||Select speed M2 “MEDIUM”|
|P||80||Select speed M2 “FAST”|
|Q||81||Select speed M3 “FINE”|
|R||82||Select speed M3 “SLOW”|
|S||83||Select speed M3 “MEDIUM”|
|T||84||Select speed M3 “FAST”|
|U||85||Select speed GRP “FINE”|
|V||86||Select speed GRP “SLOW”|
|W||87||Select speed GRP “MEDIUM”|
|X||88||Select speed GRP “FAST”|
Note: Be sure that before open the serial port with your software, the microcontroller “clock” (via internal oscillator, via external crystal oscillator,..) is stable, otherwise it will cause a lot of communication errors.
And … It worked! (on Monday 02:00 A.M…)