Research & Design Hub  Insights 

LOG IN REGISTER About Us 

Tech News  Resources  Type 
Community here to search...        

Advertise 

Inspiring the Evolution of Embedded Design.

Home Magazine  NEWSLETTER Research & Design Hub  Insights  Tech News 

Resources  Community  Advertise 

Projects • Research & Design Hub

Build a 4-DOF Robotic Arm (Part 1)

12/01/2019

By using our site, you acknowledge that you have

read and understand our Cookie Policy
x and our
1 POST REMAINING
SUBSCRIBE | LOGIN
Privacy Policy. ACCEPT
     

P ROJ E C T S

Controlled
MQ Telemetry
Circuit
Transport Written
Breaking
(Part 2) by Raul Alvarez Torrico

Using MATLAB and Arduino

When it comes to building your own robotics systems, the future is truly
now, thanks to inexpensive hardware and software tools available today. In
this project article, Raul explains how he built a robotic arm with four
degrees of freedom (4-DOF) and revolute joints. For anyone interested in
introductory robotics, this low-cost hardware and software platform lets
you get up and running.

I
n this article, I discuss my project that implements a robotic arm with four degrees of
freedom (4 DOF) and revolute joints (often denoted as RRRR), for the purpose of studying
and experimenting with forward/inverse kinematics and PID control basics applied to
robotic arms. It uses a DC motor with a bi-phase encoder for the Orst joint at the base of
the arm, and digital servo motors for the remaining three joints—including one additional servo
motor for the end eQector. The angular position of the DC motor is controlled with a PID control
loop. The remaining servo motors are controlled with open-loop control signals, because servo
:
 motors already have closed-loop controls implemented in hardware.

The robotic arm has an embedded controller that runs the PID algorithm for controlling the
angle of the DC motor, and also controls the servo motors. In addition, for changing joint angles,
it implements a communication interface to receive commands through the serial port.

The forward and inverse kinematics algorithms are implemented using Mathwork’s MATLAB
programming language. They are run in a companion computer, which interfaces to the
embedded controller by using the serial communications command interface. The MATLAB code
also implements a Graphical User Interface (GUI), from which the user can control the robotic
arm and run the forward and inverse kinematics algorithms. A 3D simulation/visualization of the
robotic arm is displayed in the GUI in real time.

The aim of this project is to provide anyone interested in introductory robotics with a low-cost
hardware and software platform that allows easy experimentation with forward and inverse
kinematics algorithms, PID control and controller/computer interfacing.

Figure 1 is a block diagram showing the main components of the robotic arm. The embedded
controller determines the pose of the robotic arm by commanding each of the four joint motors
to the desired angles. It implements a serial command interface with a very simple ASCII string
protocol for receiving target angles from the companion computer. It also implements a PID
control loop for controlling the rotation angle of the DC motor at joint 1.

FIGURE 1
Robotic arm block diagram

To do so, it reads the current motor position from the bi-phase encoder attached to the DC
:
 motor, and computes the required PID output signal to drive the motor to the target angle. The
servo motors are handled much more easily by using only an open-loop control scheme. As
noted earlier, forward and inverse kinematics algorithms are written in MATLAB and run in the
companion computer. Both algorithms return a set of angles for each of the four joints, which
are then sent to the embedded controller via the serial communications interface. For the
companion computer, I’m using a regular personal computer with Windows 10 operating system
installed.

— ADVERTISMENT—

—Advertise Here—

ELECTRONICS HARDWARE
The circuit schematic for the robotic arm is shown in Figure 2
2. For the embedded controller, I’m
using an Arduino UNO board, which is very intuitive for beginners and makes it easy to interface
a wide variety of sensors and actuators. With it, there is no need to worry about low- or mid-level
drivers and libraries for performing basic functions—such as driving a motor, doing serial
communications or managing external interrupts.

FIGURE 2
:
 Circuit schematic for the robotic arm

Case in point: I’m using the Arduino microcontroller’s (MCU) external interrupts to promptly
detect the ticks generated by the encoder attached to the DC motor in joint 1. Fast tick detection
and counting is very important for the PID control algorithm. Besides, the Arduino UNO board is
low-cost and easily programmed just by using an ordinary USB cable. The cable also can be used
to interface the board with the MATLAB code running in the companion computer, by opening it
as a virtual serial port.

I have chosen a DC motor for the Orst joint at the base of the robotic arm speciOcally to illustrate
angular position embedded PID control. By including it as a hardware and software
implementation example, it serves as a means of studying the concept; hopefully easy to
understand for those new to this concept. And, by including it as a hardware and software
implementation example, it is easy to understand for those new to this concept. For the other
joints, I chose servo motors to keep the rest of the code simpler. Arguably, all servo motors can
be replaced by DC motors by just duplicating the hardware and PID control code that already
works for joint 1. I would recommend beginning by replacing just one servo motor and once it
works well, proceed with the next, and so on. The kinematics code in the companion computer
should work just One with the replaced motors, because it is totally independent of the
hardware implementation of the robotic arm.

The DC motor at joint 1 is a generic JGY370 DC motor [1] that spins at 6 RPM when powered with
6 VDC. It has a torque of 14 kg- cm, which is more than enough to rotate the whole robotic arm
horizontally, and it comes with an attached generic bi-phase encoder. The motor is driven by a
STMicroelectronics L298, 2-channel H-bridge Driver Module. If you want to try DC motors with
PID controls in the rest of the joints, Orst make sure to have motors with the required torque for
each joint. This is important because the torque necessary to rotate weights in a vertical plane
generally must be greater than that for rotating them in a horizontal plane.

The bi-phase encoder attached to DC Motor 1 has a resolution of 6,300 ticks per revolution (that
is, it provides 6,300 pulses every full rotation). Theoretically, this gives a resolution of 17.5 ticks
per degree, which is more than enough for our robotic arm. If you use an encoder with a
diQerent resolution, don’t forget to change the related constant ENC_TICKS_PER_REV in the
Arduino code, otherwise you won’t get the exact commanded angle. If you don’t know the
resolution of your encoder, you can measure it by commanding the motor a certain amount of
degrees (say, 360 degrees or more), print the ticks in the Arduino IDE’s serial monitor, and then
use the “rule of three” to obtain the number of ticks per revolution for your encoder.

MORE ON THE JOINTS

For joints 2 to 4 and the end eQector or “gripper,” I’m using JX Servo PDI-6221MG 20 kg-cm digital
servo motors [2]. Digital servo motors have smaller dead bandwidth compared to typical analog
ones. This helps to reduce vibration when the links are horizontally extended and the servo
motors are holding against downward rotational forces generated by the arm’s weight and load.
I’m powering the servos with 6 VDC, which is the maximum allowed power voltage for these
:
 servo motors, to obtain their maximum torque performance. Lower torque servo motors can be
used for joints 3, 4 and the gripper, but I’m using the same servos on all joints because that’s
what I had at hand.

The power supply must be able to provide the required current for all motors. I have connected
my bench power supply adjusted to 6 VDC, which can provide up to 5 A. The Arduino UNO board
is powered from the USB cable connected to the companion computer, which also powers the
bi-phase encoder.

Finally, for the companion computer, I’m using a regular laptop with MATLAB R2015a installed
on it. Any personal computer can be used, provided that it has the minimum recommended
speciOcations to run MATLAB software.

For the mechanical frame, I picked an oQ-the-shelf aluminum robotic arm kit [3] to ease the
mechanical implementation and concentrate all eQorts on the electronics and code parts of the
system. This is a generic kit very popular among beginners. It’s really easy to put together in a
couple of hours, and has all parts for a complete robotic arm structure. I built a wood base to
which I attached the robot arm with screws, to have a more solid stand. Figure 3 shows the
robotic arm assembled with all its parts.

— ADVERTISMENT—

Embedded
Embedded VISIT SITE
Engineering
—Advertise Here—
:
 FIGURE 3
Fully assembled robotic arm

It is important to have motors with the correct torque speciOcations for each one of the joints,
otherwise they would not be able to counter the rotational torque in each joint due to the weight
of each link and their corresponding loads. There are free online apps to calculate torque for
robotic arm joints [4]. You need to provide inputs, such as the conOguration of the robotic arm
(how many degrees of freedom it has), link lengths, link weights, loads and so on.

They’ll compute the necessary torque for each joint for the worst-case scenario—lifting weights
at 90 degrees from the vertical—that is, with the links horizontally fully extended. If you don’t
want to deal with the calculations, it is possible to set the torques by trial and error, testing the
motors with their links at 90 degrees from the vertical and with full loads, and oversizing them a
bit just to be sure they will cope well with the loads. There’s a Ofth servo motor for the end
eQector (the gripper). However, it doesn’t get counted as a degree of freedom for the robotic
arm, so I will ignore it when talking about kinematics.

EMBEDDED CONTROLLER
The embedded controller Ormware is written in C/C++ for the Arduino platform. I’m using the
“Servo” and “Serial” libraries included by default in the Arduino platform to control the servo
motors and to do the serial communications. Although a PID control library for Arduino is also
available, I chose to write my own PID control routine. I did this because I wanted to show how
to implement it in code “by hand,” for those who are new to it. Besides, it is more portable, in
case you want to try PID in another MCU platform. The embedded controller also implements a
low-pass Olter for Oltering angle readings, and a serial command parser, which will be discussed
:
 in more detail later.

The embedded controller receives angle commands for each of the joints from the companion
computer through the serial port, in a very simple protocol format devised for that
purpose. Figure 4 shows an example of angle data packed for DC Motor 1 in the
aforementioned protocol. The angle value is packed along with some delimitation symbols.
These delimitation symbols help the embedded controller to discriminate the angle data in the
received frames. Figure 5 is an example of angle data packed for all four joints. The embedded
controller detects the delimitation symbols when parsing the serial data, and can easily know
which characters correspond to angles and for what joints. When an Arduino board is connected
to a computer, it is recognized by the operating system as a “virtual serial port,” so to send data
from MATLAB, we just have to open the virtual serial port in code and send the data in ASCII
format.

FIGURE 5
Packed angle data for all four motors

FIGURE 4
Packed angle data example for DC Motor 1

This serial interface also becomes handy when debugging the basic angle control of the joints.
We can manually open the virtual serial port in Arduino IDE’s serial monitor, or by using any
other terminal emulator software (such as Putty or Tera Term), and send angle command data
frames by typing them in the format shown in Figure 4 and Figure 5. In fact, it is highly
recommended to test and debug the hardware in this way before connecting the robotic arm to
the companion computer. This allows the correct rotation of every joint to be checked, before
interfacing the arm with the MATLAB code.

PID CONTROL AND FILTERING

A PID (proportional–integral–derivative) controller is a control-loop mechanism widely used in
many control systems, including robotics [5]. This controller calculates an error value as the
diQerence between a desired setpoint (in our case, some desired angle for joint 1) and the actual
measured process variable (the actual measured joint 1 angle). It then uses this error to
calculate an output signal composed of the sum of three terms: The proportional, integral and
derivative (P, I and D, hence the given name). The output signal then is applied to the actuator as
a correction signal to drive the error to zero—or more realistically, within a given error tolerance
:
 that the system can cope with. The PID control uses a feedback loop to measure the error
iteratively, calculate and apply the output signal to the actuator. This closed-loop conOguration is
what makes this type of control very responsive, accurate and independent of external system
parameters. Figure 6 is a graphical representation of the PID controller used with the DC motor
at joint 1.

FIGURE 6
PID control loop for DC Motor 1

Every time a sensor is used to read some variable in the environment (such as position or
velocity), a certain amount of noise (typically random) will always be present in that reading. This
noise is due to some factors such as the error tolerance of the sensor itself, including external
perturbations in the environment and magnetic interference. Generally, this sensor noise will be
a high-frequency signal in comparison with the frequency of the signal or data of interest. It
tends to mess with the performance of the PID controller, because the controller will try to react
to the high-frequency oscillating noise, instead of trying to correct for the signal of interest. That,
in turn, will cause oscillations in the system and also make it more discult to tune the PID
constants.

Some systems are more sensitive than others to noise. It depends on their speciOc
characteristics. For systems that are very sensitive to noise, a Olter helps to reduce the amount
of noise present in the sensor data, thus improving the performance of the PID controller. I
implemented a low-pass, moving-average Olter in the embedded controller [6] to smooth the
high frequency noise and help the PID algorithm to drive the motor more easily to the desired
angle. This kind of Olter is generally the easiest way to implement sensor noise Oltering in an
MCU. It is very popular and works well with many types of sensors.

A PID control system has three tuning constants, Kp, Ki and Kd, which control the gain or
contribution of each of the three terms (proportional, integral and derivative) to the output
signal sum. By appropriately setting these three constants, we make the system’s response to
error as fast and stable as possible. The PID constants I provide in the Arduino code work well
with my setup, but may not work as well with yours if you deviate somehow from the proposed
hardware.

For example, you might have diQerences in motor velocity, encoder resolution, joint friction and
:
 mass of your robotic arm structure. In that case you may need to re-tune the three constants
from zero. Depending on your previous experience with PID, there are some tuning methods
you can use, the easiest of which—iterative trial and error—is generally recommended for
beginners. (I use it all the time.) There are many resources on the Internet for learning how to
use it, in case you aren’t familiar with it.

MATLAB GUI BASICS

Figure 7 shows the GUI that I made for the robotic arm, using MATLAB’s GUI Development
Environment. In the following paragraphs I’ll explain some basic concepts about how a GUI
works in MATLAB, and how it interfaces with the application code to perform the desired tasks. I
won’t explain how to build the GUI from scratch, but there are some online tutorials if you want
to learn how to do it.

FIGURE 7
MATLAB Graphical User Interface

In a MATLAB GUI, the components used to input data—such as buttons, sliders and check boxes
—are generally attached to callback functions in code. So, any time you interact with one of
these components, for example, by clicking a button or moving a slider, its corresponding
callback function is called. This means that these callback functions must contain all the code
you want to run in response to interactions with these controls.

The provided MATLAB code Ole “Robotic_Arm_GUI.m” contains all GUI callback functions. For
instance, when the “Motor 1 Angle” slider is moved (Figure 7),
:
 the slider_motor1_angle_Callback() function is called. Inside it, the following tasks are
performed: get the new angle value for Motor 1 (set by the moved slider); compute the forward
kinematics and plot the new resulting pose; update the “Motor 1 Angle” text label in the GUI with
the new angle value; update also the resulting X, Y and Z coordinates of the end eQector (the tip
of the arm) in the corresponding coordinate sliders and text labels; and Onally, send the new
angles through the serial port to the embedded controller, for moving the robotic arm to the
new pose. The same applies for the other angle sliders.

Also, when the ”X Coordinate” slider is moved, the callback

function slider_coordx_Callback() is called to perform the following tasks: it reads the
values from all three coordinate text labels (X, Y and Z), and stores them in an array (these are
the target coordinates to move the arm by running inverse kinematics); then, it updates the
changed coordinate value in the X-coordinate’s text label. When the “Run Inverse Kinematics”
button is pushed, the button_calc_invkin_Callback() function is called. It will read the
previously stored target coordinates and run the inverse kinematics algorithm to compute new
angles for each one of the joints, plot the new pose in the GUI, and then send the angles to the
embedded controller. The same applies for the Y and Z coordinates.

When the “Reset to Start Pose” button is pushed, the button_reset_Callback() function is
called. It resets all angles and coordinates to their initial values, updates the robotic arm’s pose
in the GUI and sends these initial angles to the embedded controller to reset also the real
robotic arm.

— ADVERTISMENT—

The PLC software is successfully

sl-automation.de
PLC Analysis
used by customers
(ServiceLab)
from almost OPEN
DASYLab
all industriesSPS Edition

—Advertise Here—

The MATLAB GUI code also has an “opening function”

called Robotic_Arm_GUI_OpeningFcn() that runs once, when the GUI window is created. It
also has a “closing function” called figure_gui_CloseRequestFcn() that runs every time the
GUI window is closed. In the opening function, the following tasks are performed: open the
virtual serial port associated with the Arduino UNO—don’t forget to change this for your own
before running the MATLAB code; set all initial values for the robotic arm (for example, angles,
coordinates, link parameters); and plot the robotic arm’s initial pose in the GUI. In the closing
function, the most important task performed is closing the serial communications port, because
if left open, the application will throw an error the next time it runs and tries to access it.

MATLAB COMMS AND PLOTTING

To send data from the companion computer to the embedded controller via the virtual serial
port (that is, the Arduino UNO’s USB cable connected to the computer), the serial port must be
properly conOgured and open. This is easy to do with the available serial port functions in
MATLAB. (See the aforementioned “opening function” in the code.) Sometimes, when debugging
:
 the serial communications, the MATLAB code will crash without properly closing the serial port.
If this happens, you can type “instrreset” in the MATLAB Command Window to close the serial
port that was left open, before running the code again.

Once the serial port is open, sending data to the embedded controller is just as easy as calling
MATLAB’s “fprintf” function. For instance, fprintf(serial_port, strcat(‘2$’,
num2str(round(angle2)), ‘&’)) sends the angle data frame for servo motor 2. Finally, in
the “closing function,” the serial port will be closed before Onishing the MATLAB application.

The Run_Plot_Fwd_Kinematics(theta1, theta2, theta3, theta4) function (contained

in the “Run_Plot_Fwd_Kinematics.m” Ole) is in charge of plotting the robotic arm pose in the GUI.
This function receives as parameters the new joint angles of the robotic arm, and calls inside
the Calc_Fwd_Kinematics(dh_params) function. This function calculates the forward
kinematics and returns a matrix containing the X, Y and Z coordinates of the ends of each one of
the robotic arm’s links. These coordinates will then be used by the caller function to plot the
arm’s graph in the GUI.

For simplicity, I’m using a simple “wire graph” plot of the robotic arm links (no fancy 3D stuQ!) to
keep the code readable for those who are new to MATLAB programming. The “plot3d” function
used for this purpose basically takes as arguments three vectors of the X, Y and Z coordinates
(among other arguments, such as line width and color), and lets you draw lines and dots in three
dimensions. I’m passing as arguments the Orst three rows of the matrix returned by the forward
kinematics calculation, which contain the X, Y and Z coordinates of both ends of every link in the
robotic arm to plot the arm’s pose. Every time the pose changes, the forward kinematics is
calculated again to obtain the new coordinates, and the plot is refreshed in the GUI.

WHAT’S NEXT?
Figure 8 shows the complete system, comprising the robotic arm, the embedded controller and
the companion computer. The project Oles for this project are available on Circuit Cellar’s article
code and Oles download webpage. In those project Oles, there are detailed instructions for
setting up and running the system.
:
 FIGURE 8
Robotic arm, embedded controller and companion computer

In Part 2 of this article series, I’ll be discussing topics more related to the mathematical
foundations of robotics, such as conOguration spaces, robot pose representation in three
dimensions, homogeneous transformations, Denavit-Hartenberg parameters, direct kinematics
and inverse kinematics with the pseudo-inverse Jacobian. I’ll also talk a bit about testing, my
conclusions and future improvements. Part 2 is scheduled to appear in the February 2020 issue
(Circuit Cellar 355). Stay tuned!

For detailed article references and additional resources go to:

www.circuitcellar.com/article-materials

References [1] through [6] as marked in the article can be found there.

RESOURCES
Arduino | www.arduino.cc
Mathworks | www.mathworks.com
STMicroelectronics | www.st.com

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • DECEMBER 2019 #353 – Get a PDF of the issue

Keep up-to-date with our FREE Weekly Don't miss out on upcoming issues
Newsletter! of Circuit Cellar.

Subscribe to Circuit Cellar Magazine

Would you like to write for Circuit Cellar? We
are always accepting articles/posts from the
Note: We’ve made the May 2020 issue of Circuit Cellar
technical community. Get in touch with us available as a free sample issue. In it, you’ll Ond a rich
and let's discuss your ideas. variety of the kinds of articles and information that
exemplify a typical issue of the current magazine.
:
 Sponsor this Article

Raul Alvarez Torrico

TecBolivia | + posts

Raul Alvarez Torrico has a B.E. in electronics engineering and is the founder of TecBolivia, a company
oQering services in physical computing and educational robotics in Bolivia. In his spare time, he likes to
experiment with wireless sensor networks, robotics and artiOcial intelligence. He also publishes articles
and video tutorials about embedded systems and programming in his native language (Spanish), at his
company’s web site www.TecBolivia.com. You may contact him at raul@tecbolivia.com

#Arduino #embedded controller #MATLAB #robotics #Servos

Controlled Circuit Breaking

:
 

Semiconductor Fundamentals (Part 4)

You may also like

EE Tips • Resources Tech News

Open-Source Guide for July Circuit Cellar: Sneak
Embedded Systems Preview
Developers (EE...

EE Tips • Resources Insights • Tech The Future

Processing, Wiring, and The Future of Robotics
Arduino (EE Tip 101) Technology

Research & Design Hub • Tech Projects • Research & Design Hub
Trends Build a Simple Quadcopter
Box-Level Systems Marry AI Drone
and IoT

Get our FREE Newsletter!

---

Magazine Sponsor — ADVERTISE

ADVERTISMENTS
:
:
Embedded Engineering
Embedded

Embedded Engineering
Embedded

Embedded Engineering
Embedded
:
 Supporting Companies Upcoming Events Current Issue: April

Sensors

◊ Inside
This Issue

◊ Digital
Login
◊ Article
Code

◊ Subscription Help
◊ Back Issue (PDFs)

◊ Subscribe

Copyright © 2023 KCK Media

Corp.
All Rights Reserved

Copyright © 2023 KCK Media Corp.

: