519f61f94be81Design of a Robot Control Embedded Computer

8/12/2019 519f61f94be81Design of a Robot Control Embedded Computer

1/12

Design of a robot controller

embedded computerProject Laboratory II

Opra Istvn Balzs (MI3GJG)

Consultant:

Dr. Kiss Blint

Budapest, 23 May, 2013


2/12

2

Overview

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

implementation.

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

generation.

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.


3/12

3

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 10Vas 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

10Vand 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


4/12

4

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

[8]).

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


5/12

5

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 levelso the LDO needs to source this 30mA.

This means a dissipation of 30mA*13V = 0.4W. I have included a small heat discharge coppersurface 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


6/12

6

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 levelwhen 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 intoall 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 firstchannel 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 dontmove 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

buttons.

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


7/12

7

derivatives (since our robot has rotational joints these are angle, angular velocity and

angular acceleration). is the so called generalized inertia matrix, is a memberresponsible 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 translationswhich 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 thesegments. 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 isderived 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: , , .Here and are the inertias. The in the form derived from the Lagrange equation iscomposed of matrices, which can be calculated using . Theresulting nonzero elements are:

.

From here the full dynamic model:

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


8/12

8

Here the indices mean that those are the reference signals, the -s without indices areactual measured values from the robot. To determine the gains , and , we canwrite the above equation in the following form: . This can beconsidered 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 alsothe new values, then using these it has to produce the output torque values using4. Implementation of the CTT controller


9/12

9

. I used a continuous integrator block in for the integrator branch of thePID, 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 wecan 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


10/12

10

[

]

(

)

, 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 calculatingafter 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.


11/12

11

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

simulationinstead 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.


12/12

Documents

519f61f94be81Design of a Robot Control Embedded Computer