You are on page 1of 12

Design of a robot controller

embedded computer
Project Laboratory II
Opra Istvn Balzs (MI3GJG)


Dr. Kiss Blint

Budapest, 23 May, 2013


In the Project Laboratory II subject I continued the development of the embedded control
unit I started building during my BSc thesis. The starting resources were the already finished
software and hardware components of the control unit, and I have made improvements to
both during the semester. I have also created a robot controller algorithm which is
compatible with the hardware unit.

In the following I will first go into detail about the hardware development, then I will show
the changed software architecture. Finally I will describe the controller algorithm and its

Introducing the robot and the control unit

The robot I am developing for is a two rotational degree of freedom arm, which can move in
a single plane. The segments of the robot are constructed from aluminum bars. The
actuation of the segments is performed by two brushed DC motors (Maxon RE-25-118755
[1]). Both of these are operated from a servo amplifier [2], which supplies current to the
motors. The current output of the amplifiers is proportional to the voltage level (10V) on
their input. Since the torque of DC motors is proportional to their current, this configuration
makes it possible to set the motor torque via a voltage signal. Feedback is provided from the
segments by incremental transducers mounted on the motor axles.

After the physical construction of the robot, design of controller algorithms started in the
Matlab Simulink environment. Controllers created in Simulink could be run on a dSPACE
rapid prototyping card installed in a host PC via Simulink Real Time Workshop code

I had to take all of the above into consideration when designing the control unit. I have built
most of the hardware and written software in the previous two semesters. In this semester I
already had the main board (12cm x 15cm), which could receive and process signals coming
from the incremental transducers and had a working human-machine-interface in the form
of a 12 key keyboard and a character LCD display.

The ICs processing the incremental transducers are connected via SPI bus to an AT90CAN [3]
Atmel microcontroller. On the same SPI bus is the DA converter as well this was not yet
implemented. The screen and keyboard is connected to another AT90CAN, the two
controllers can communicate via CAN bus. The main computational unit on the board will be
an MPC555 based microprocessor card, which only needs to be plugged in to its socket when
it will be available. This processor card will run the control algorithm, and will use the CAN
bus to interface with the microcontrollers. Thus the controllers main function is to facilitate
IO with the robot and the user.

Integrating the DA converter

A key step in making the controller unit fully operational was to add the DA converter to the
system. I have chosen the Texas Instruments DAC7734 0 for the task. This converter IC is
16bit, communicates via SPI bus, and has four output channels. The long term plans for the
controller include control of three joint robots (like adding another segment to our 2-DOF
robot), so three of the four channels will be used. The DA is also capable of supplying a 10V
range signal on its output, so no signal level conversion is needed, it can be directly
connected to the servo amplifiers.

These optimal qualities come at a cost however: this DA requires five different input
voltages. First it needs +5V for inner logic and SPI bus operation. It also needs 15V to supply
the analog outputs, and 10V as a reference for the minimum and maximum output levels.
The +5V was readily available from the switching DC-DC converter already realized and
connected to the controller board, what was left is to add a sub power unit to supply the
10V and 15V.
Power source for the DA

To do this I have designed a small (4.5cm x 4.7cm) PCB which could be connected to the
power unit producing the +5V and +3.3V.

1. Layout of the power unit

The block diagram
demonstrates the basic
operation of the board. The
input voltage is from the
adjustable voltage output
main power converter,
which supplies the motors
and the whole controller
board. (Its voltage can be
adjusted between around
18.5V and 24V, but my
controller unit only
tolerates voltage up to 23V,
so care needs to be taken
with this.) An LDO (Texas
Instruments TPS7A4700 [5])
creates a stable +5V from
this, which is then fed to a
voltage inverting switching
converter circuit (the
switching unit is the Texas
Instruments TPS63700 [6]), this creates the -15V. Another LDO of the same type is used to
generate the +15V. The 10V levels only have to source around 6mA, so I used a precision
reference IC for the +10V (Texas Instruments REF5010 [7], this is capable of sourcing up to
30mA). To create the negative 10 volts, I used an inverting operational amplifier (TI OPA277

During the design of the layout I put greater emphasis on designing sufficiently short and
wide connections for the switching converter, since this unit uses a 1.4Mhz switching
frequency, thus failure to design connections with minimal length and curvature can lead to
3. Inverting op-amp schematic
2. Block diagram of the power unit

unreliable operation. To ensure the best results I have used the reference layout provided by
Texas Instruments in the datasheet of the switching IC.

After verifying the design I have ordered the PCB from the Electronic Technology
Department of the University. Then I have assembled the unit and tested the operation. The
voltage levels on the output were approximately correct (actual levels: +14.82V, -14.85V,
+9.95V, -9.93V), and were well within the required ranges of the DA chip. The current
consumption however was considerably higher than I expected, requiring some 70mA to
operate. The most strain is on the LDO creating the +5V level. The IC itself can source up to
1A, but there is increased heat dissipation due to the 13+ volt drop when it converts the
+18V+ to 5V. I attribute the increased current consumption to the fact that the switching
converter has to create -15V from +5V. The converter has a minimal internal resistance, but
even then to supply 10mA (estimated maximum requirement on the DAs part) on the +15V
level it needs at least 30mA on the +5V level so the LDO needs to source this 30mA.

This means a dissipation of 30mA*13V = 0.4W. I have included a small heat discharge copper
surface for the LDO on the bottom of the board, but during operation both this surface and
the IC get uncomfortably hot. To ensure long time reliability it is required to ensure flowing
air cooling and possibly even to add a metal heat sink to the copper area. Another option is
to remove the LDO from the circuit by cutting the copper connection on the board and to
provide the 5V for the switching converter from the main power converter already creating a
stable 5V level capable of sourcing 1.5A.

Adding the DA and configuring the software

After checking the correct operation of the new power unit, I have soldered the DA onto the
main board along with the required noise filter capacitors. In the meantime I have written
the software components required for communication with the converter. As I have
previously mentioned, the DA communicates on SPI bus. The AT90CAN controller has built
in, hardware supported SPI capability. Aside from the SPI, the DA needs a few other inputs as
well. Its outputs are double buffered, meaning that each of them has a 16 bit register which
can be written into without changing the current output value, and then the outputs can be
updated simultaneously to the new values in the registers.

First one has to send a 3 byte long code on the SPI bus, the first byte specifies which register
to write to, and the following 2 bytes are the output data. To actually write the value into
the buffer register, a rising edge on the LDAC input pin is required. Then, to update the
outputs, one has to apply a falling edge on the LOAD input pin.

The IC also has an RSTSEL input pin, which determines the starting output levels after a
reset. A high level means the output is set to the middle level this is required for our
application, since the middle level is 0V (extremes being 10V), and any other startup output
voltage would result in sudden jerky movement in the robot when turning on the system.

I first wrote simple functions which set the aforementioned inputs and the Chip Select of the
IC high or low. Using these I wrote an initializing function which is run immediately on
startup. This gives a reset signal to the IC. Since the startup of the controller is not

instantaneous, sadly there is a fraction of a second, before the reset signal arrives to the DA,
when the outputs are minimum value, causing a small jerk in the robot. This issue has to be
addressed in the future.

There are also the quadrature decoders (the ICs which process the incremental transducers
signal) on the very same SPI bus. These ICs require that the SCK of the SPI bus is low level
when idle. In the DA the Chip Select and the SCK inputs are simply fed to a logical OR gate.
This means that if the SCK input is low, a rising edge on the Chip Select will be interpreted as
a clock tick by the IC. So if the idle level of the SCK is low, removing the active (low level) chip
Select after a transmission will shift another, invalid bit into the DA, completely corrupting
the input data. To solve this it is necessary to use a high idle level SCK meaning that when
the controller switches between communicating with the DA and the quadrature decoders,
the SPI configuration (SCK idle level) needs to be changed.

Thankfully the AT90CAN is capable of both SPI operation modes, and switching between
them requires merely changing two bits of a register. I have incorporated this switching into
all of the functions which facilitate SPI communication. I have written separate functions for
updating three of the four of the output buffers on the DA. A future developer only needs to
use these (update_DA_A(U16 value), update_DA_B(U16 value), update_DA_C(U16 value))
and the DA_LOAD_high() and DA_LOAD_low() functions to work with the converter.

To test different output values on the DA I used the keyboard as an input source. I have
modified the program of the controller handling the keyboard that the press of the button
labeled 1 sends two data bytes containing 0x7778 in a CAN packet to the other controller.
Pressing the 4 button sends 0x8000, and pressing 7 sends 0x8888. Upon receiving these
messages, the other controller writes the received data into the output buffer of the first
channel of the DA. The output voltage values are 0.66V for buttons 1 and 7, and 0.044V for
button 4 (this should be 0V, but the offset is due to the asymmetry of the reference sources.
In the end this proves to be a non-issue, because the motors dont move with this output
level. Although in the future this could be corrected by offsetting in the controller software).
With this software configuration I was able to rotate a segment of the robot by pressing the

Creating a control algorithm

With the adjustments mentioned above the control unit is ready to physically interact with
the robot, both in setting the motor torque and in receiving the position feedback. The next
step would be implementing some form of a controller. This requires the MPC555 processor
card, currently not available. Nevertheless I have created a controller in Simulink which can
be immediately tested when the processor card arrives.

This is a controller operating with the Computed Torque Technique (CTT). (The following
calculations are based on the book Robotok irnytsa (Robot control) written by Dr.
Lantos Bla [9]). To implement this controller, one firstly has to write down the differential
equations representing the dynamic model of the robot. We have to reach the form of
() ( ) . Here and its derivatives are the joint coordinates and their

derivatives (since our robot has rotational joints these are angle, angular velocity and
angular acceleration). () is the so called generalized inertia matrix, ( ) is a member
responsible for the centripetal and Coriolis effects, and is the torque applied to the joints.

To start out, I had to determine the geometric model of the robot. To do this I have written
down the Denavit-Hartenberg transformations, which show the rotations and translations
which are needed to move between coordinate systems tied to joints of the robot:

Here C and S are cosine and sine of the joint coordinate in the lower index. Two lower index
coordinates mean the multiplication of the cosines or sines. The -s are the lengths of the
segments. From these forms I determined the coefficient matrices needed to calculate the
angular velocity (the matrix) and velocity (the matrix) of the segments. To do this is
derived by time the rotational part (top left 3-by-3 matrix) and the translational part (3 by 1
matrix on the top right) of the Denavit-Hartenberg forms, and used:

With these matrices I could determine H using ()

. Here

is the
inertia matrix of the given segment. This formula is derived from the Lagrange equation, and
can be written as () [

] where for our robot the D elements are:




are the inertias. The ( ) in the form derived from the Lagrange equation is
composed of

matrices, which can be calculated using

). The
resulting nonzero elements are:


From here the full dynamic model:

The CCT controller takes the from the dynamic model, and implements a PID controller for
it in the following form:



Here the indices mean that those are the reference signals, the -s without indices are
actual measured values from the robot. To determine the gains


, we can
write the above equation in the following form:

. This can be
considered as a ( )

system, for which we can select a suitable T time constant.

Then the gains of the PID branches can be calculated by:


Simulink implementation of the controller

I have mentioned that Real Time Workshop code generation will be used to transfer the
Simulink model onto the actual controller unit. The Embedded Target for MPC555 Simulink
toolbox has blocks which facilitate CAN bus operation of the microprocessor, and also blocks
for using the general IO pins. Using these one can interface a controller algorithm with the
outside world signals coming to and going to the robot. For the code generation to work,
one has to conform to some restrictions when creating the Simulink model.

Such restriction is that level 2 S-Functions cannot be used, since these are not supported by
the Target Language Compiler supplied with the Embedded Target for MPC555. I had to
resort to using only Embedded Matlab functions while implementing the controller.
In each iteration the controller has to calculate the new values of () and ( ), and also
the new

values, then using these it has to produce the output torque values using
4. Implementation of the CTT controller

() ( ) . I used a continuous integrator block in for the integrator branch of the
PID, all other calculations are implemented as code in the Embedded Matlab Function.
I also created a test system to verify the operation of the controller. I implemented the
dynamic model used in the controller in a Level 2 S-Function to serve as the plant in lieu of
the actual robot for testing purposes.
The controller requires a reference joint coordinate signal, and its first and second
derivatives. I created a simple trajectory design method in the test model to provide these.
The basis of the method is that during movement between the initial A and final B
coordinates, there should be no sudden changes in the velocity and acceleration, they both
need to be continuous, differentiable functions. The constraints are that the initial position is
A, the final position is B, and the velocity and acceleration must be zero both at the initial
and final moments of the movement. These are a total of six constraints; based on these we
can determine a fifth order polynomial as a function of time, which will be the joint
coordinate reference signal.

From this we can see that the velocity reference will be a fourth order polynomial and the
acceleration will be a third order polynomial function of time. We can use linear algebra to
determine the coefficients of the polynomials. We can write the whole set of constraints as a
matrix sum:
5. Test system for the controller


, where C is the matrix containing the coefficients.

We can easily solve this equation for C by multiplying from the right side with the inverse of
the matrix containing the time values.

I implemented this method in an Embedded Matlab Function, its inputs are A, B and T, the
desired movement time. Another block then uses the computed coefficients to produce the
actual time signal, using the equation above. It is important to note that the polynomials will
behave as required only between zero time and T, so we must make sure to only run the
calculation between these time coordinates. I made sure of this by feeding T into the time
signal generator block as well, and adding a condition which makes sure to stop calculating
after the actual time exceeds T, and only output the last calculated values from then on.

To properly test the controller I set the initial coordinates to zero degrees in the dynamic
model (meaning that the robotic arm is fully extended), yet specified a non-zero starting
condition in the trajectory design, 20 degrees for the first joint and 120 degrees for the
second one. I specified a movement time of 3 seconds, within this time the transients
decayed and by the end the joint coordinates settled exactly onto the level specified by the
reference signal.

Upcoming tasks

The next major step in the development will be adding the MPC555 processor card to the
system, and testing the controller. It would be ideal to first use Hardware-in-the-Loop
simulation instead of using the actual robot the dynamic model could be ran on the dSpace
rapid prototyping card, and its signals could be interfaced with my controller to fully verify
operation. Only after that should be the controller connected to the physical robot.

Another important development path is adding the Bluetooth controller to the board the
layout can accommodate a Bluetooth telecommunication module. With this it would be
possible to establish a Runtime Interface between an instance of Matlab running on a
computer and my controller unit. Another possibility would be connecting a Bluetooth-
capable smartphone running Android to the system.



[1] Maxon RE25 118755 motor datasheet
[2] Maxon 4-Q-DC Servoamplifier datasheet
[3] Atmel AT90CAN microcontroller datasheet
[4] Texas Instruments DAC7734 datasheet
[5] Texas Instruments TPS7A4700 datasheet
[6] Texas Instruments TPS63700 datasheet
[7] Texas Instruments REF5010 datasheet
[8] Texas Instruments OPA277 datasheet
[9] Lantos Bla: Robotok irnytsa, 1997.
ISBN: 9630562170