Proceedings of the ASME 2014 Dynamic Systems and Control Conference

DSCC2014
October 22-24, 2014, San Antonio, TX, USA

DSCC2014-5846

EVALUATION OF A LOW-COST MICROCONTROLLER FOR REAL-TIME CONTROL

EDUCATION AND PROTOTYPING

Ryan W. Krauss

Associate Professor
Mechanical and Industrial Engineering
Southern Illinois University Edwardsville
Edwardsville, IL 62026
Email: rkrauss@siue.edu

ABSTRACT
Arduino microcontrollers are popular, low-cost, easy-to-
program, and have an active user community. This paper seeks
to quantitatively assess whether or not Arduinos are a good fit
for real-time feedback control experiments and controls educa-
tion. Bode plots and serial echo tests are used to assess the
use of Arduinos in two scenarios: a prototyping mode that in-
volves bidirectional real-time serial communication with a PC
and a hybrid mode that streams data in real-time over serial.
The closed-loop performance with the Arduino is comparable to
that of another more complicated and more expensive microcon-
troller for the plant considered. Some practical tips on using an
Arduino for real-time feedback control are also given.
NOMENCLATURE
u closed-loop system input
v command voltage sent to the plant
e error signal between desired and actual plant output
SFLR single-flexible-link robot (experimental plant)
θ encoder output for the plant (SFLR)
θd desired encoder position (closed-loop input)
ẍtip tip acceleration for the SFLR
Gθ (s) position control transfer function
Ga (s) vibration suppression transfer function
Introduction
In order to ensure performance and stability, experiential
feedback control systems must read sensor signals and send com-
mand signals at hard real-time intervals typically on the order of
1-10 millisecond. This can be surprisingly challenging and the
need has lead to a number of commercially available hardware/-
software solutions to the problem. These systems have been
well-received by students in feedback control courses [1, 2, 3].
These solutions can cost several thousand dollars per lab station.
A number of open-source and lower cost solutions to this prob-
lem have been presented in the literature [4, 5, 6, 7, 8].
Microcontroller-in-the-Loop Systems
One approach to low cost, real-time feedback control is a
microcontroller-in-the-loop (MIL) system [7, 8, 9, 10, 11]. These
systems place a microcontroller in the feedback loop and are
in some ways similar to other hardware-in-the-loop systems. If
the microcontroller is communicating with a personal computer
(PC), then an MIL system can be used for control prototyping
or other educational purposes. If communication with a PC is
no longer necessary, the MIL system essentially becomes an em-
bedded control system.
Arduino Microcontrollers
Evaluation boards for Arduino microcontrollers cost
roughly $30 each. They are very popular, open-source, and easy
to program. This paper addresses the question of whether or not

1 Copyright © 2014 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/asmep/81912/ on 05/08/2017 Terms of Use: http://www.asme.org/abo

 u e v y
controller DAC plant
− serial
ADC/Counters
PC Microcontroller
Figure 1. Block diagram of the MIL system operating in prototyping
mode.
an Arduino and a PC can be used to form a real-time MIL control
system.
This paper has two primary goals: to demonstrate the ca-
pabilities of an Arduino microcontroller for real-time feedback
control applications and to help others quickly get started using
Arduinos in controls applications. To that end, the paper presents
some methods for evaluating any microcontroller for MIL real-
time control usage along with some practical tips that are specific
to the Arduino.
Prototyping vs. Hybrid Modes
An MIL system can be used for control prototyping if it is
possible to get real-time data from the microcontroller back to
the PC. There are many low-level details associated with imple-
menting a feedback control system on a microcontroller. An MIL
system can be even more useful if it provides a means for describ-
ing the control in a higher-level language and allows the control
law to be changed quickly.
Figure 1 shows a block diagram for an MIL system operat-
ing in prototyping mode. In prototyping mode, all control cal-
culations are done on the PC in a higher level language (Python
in the case of this paper). Prototyping mode allows the control
law to be changed without reprogramming the microcontroller.
The microcontroller is used for reading the sensor signals, send-
ing the actuator signals, and enforcing the real-time execution of
the control law. Once a basic program that does these things is
loaded onto the microcontroller, the user does not need to do any-
thing else that is microcontroller specific. Users of prototyping
mode are also protected against the limited memory and com-
putational power of the microcontroller. The key bottleneck for
prototyping mode is that it requires bidirectional real-time serial
communication.
If an MIL system is only being used for controls educa-
tion, prototyping mode may be all that is necessary. However,
if the end goal is to create an embedded control system (or to
teach students about embedded systems), then the design may
progress through hybrid mode before arriving at a fully embed-
ded mode. In fully embedded mode, the microcontroller operates
completely independent of the PC. Hybrid mode refers to an in-
termediate step between prototyping and fully embedded modes.
2 Copyright © 2014 by ASME
Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/asmep/81912/ on 05/08/2017 Terms of Use: http://www.asme.org/abo
test parameters
(not real time) PC
real-time data streaming
u e v y
− controller DAC plant
ADC/Counters
Microcontroller
Figure 2. Block diagram of the MIL system operating in hybrid mode.
Figure 3. The single flexible link robot (SFLR) used as an experimental
test bed for this paper.
Figure 2 illustrates an MIL system operating in hybrid mode. In
hybrid mode, all of the control calculations are done on the mi-
crocontroller. Real-time communication only goes in one direc-
tion, data is streamed from the microcontroller to the laptop. The
laptop may send commands or parameters to the microcontroller
before the test starts, but once the test starts data only flows one
way. Real-time data streaming is necessary because the micro-
controller has very limited RAM and storing large arrays of data
would be very difficult.
Plant Description
This paper will use the system shown in Figure 3 to investi-
gate the capabilities of an Arduino microcontroller for real-time
control. The system will be referred to as the single flexible link
robot (SFLR). The robot has one flexible link driven by a DC
motor and drive train. The input is the voltage to an H-bridge
that drives the robot. The sensors include an encoder at the base
of the flexible link and an accelerometer near the tip of the link.
Figure 4 shows a block diagram of the vibration suppression
control scheme for the SFLR. There is an inner loop for motion
control based on encoder (θ ) feedback and an outer loop for vi-
bration suppression based on tip acceleration feedback.
 250
ẍtip
θd θ̂d v 200
− − Gθ (s) SFLR θ
150

Voltage (counts)
100 θd

θ
Ga(s) 50 ẍtip

0
Figure 4. Block diagram of the vibration suppression control scheme for
the SFLR of Figure 3. −50

−100
0.0 0.5 1.0 1.5 2.0 2.5 3.0
Time (sec)
Serial
Communication Figure 6. Step response for the SFLR without vibration suppression.

Command Voltage
250

Plant 200
(SFLR)
Sensor Signals
Voltage (counts) 150
Personal Microcontroller
Computer 100 θd

Figure 5. The benchmark system for this paper: a microcontroller- 50 ẍtip

controller-in-the-loop system operating in prototyping mode. The micro-

controller is more expensive and more complex than the Arduino. 0

−50

Comparison/Benchmark System
In this paper, the Arduino will be compared to a
Programmable-System-on-Chip (PSoC) microcontroller from
Cypress for suitability for real-time feedback control applica-
tions. While PSoC’s are in some ways more powerful than the
Arduino, they are also more difficult to configure and they are
more expensive. A schematic of the PSoC being used in the
microcontroller-in-the-loop (MIL) system is shown in Figure 5.
This system has been used in real-time control with digital up-
date frequencies of 500 Hz. It has also been shown to be effective
in controls education [12].
Figure 6 shows the step response for the SFLR system be-
ing controlled by the PSoC MIL approach. There is no vibration
suppression in this case. Note that the encoder signal shows that
the joint is back driven by the vibrations and it takes 2-3 sec-
onds for the vibrations to die out. Figure 7 shows the response
with vibration suppression. Note that the settling time is less
than one second. The Arduino control system will be considered
successful if it can reproduce these results, especially those with
vibration suppression (Figure 7).
−100
0.0 0.5 1.0 1.5 2.0 2.5 3.0
Time (sec)
Figure 7. Step response for the SFLR with vibration suppression.
Essential Elements of a Microcontroller-in-the-Loop
System
What is required to use a microcontroller and a computer to
effectively form a real-time control prototyping system? First,
the PC and the microcontroller have to be able to transfer small
amounts of data back and forth in real-time. The easiest way
to do this using an Arduino is with USB-to-serial. The Arduino
board has a USB port that is designed for serial communication.
The Arduino software includes a serial monitor that might be
sufficient for hybrid mode. This work used Python on the PC
side to communicate back and forth with the Arduino as well as
perform control calculations in real-time, visualize data from a
finished test, and perform control design.
In addition to serial communication, the microcontroller
must be able to read all of the sensor signals, send command sig-
nals, and enforce the real-time execution of the control law. For
the SFLR, the Arduino will need to be able to decode the A and

3 Copyright © 2014 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/asmep/81912/ on 05/08/2017 Terms of Use: http://www.asme.org/abo

 B square waves from the encoder, read the accelerometer signal TCCR1B = 0; // same for TCCR1B
using an analog-to-digital converter (ADC), and send the motor
command voltage to the H-bridge using a digital-to-analog con- // turn on CTC mode:
verter (DAC). While these are fairly basic microcontroller func- TCCR1B |= (1 << WGM12);
tions, two aspects were complicated with the Arduino.
The first challenge was related to the ADC of the Arduino, // Set CS10 and CS12 bits
which measures signals between 0 and 5 volts. There does not // for 1024 prescaler:
appear to be a built-in way to measure negative voltages. The ac- TCCR1B |= (1 << CS10);
celerometer signal can be both positive and negative. The easiest TCCR1B |= (1 << CS12);
way to handle this was to create a virtual ground at 2.5 volts us-
ing a Texas Instruments TLE 2425 precision virtual ground chip // set compare match register
and two capacitors (0.1µF and 1µF). The chip costs roughly $2. // to desired timer count:
Connecting the ground wire from the accelerometer signal to the OCR1A = 104;//150 Hz
virtual ground allows the Arduino to measure ±2.5 volts. //OCR1A = 31;//500 Hz
The second challenge was related to the Arduino’s DAC.
The analogWrite function of the Arduino sets the duty cy- // enable timer compare interrupt:
cle of a pulse width modulation (PWM) signal that by default TIMSK1 |= (1 << OCIE1A);
is running at 500 Hz. If the digital control system will update
somewhere in the frequency range of 100-500 Hz (or possibly sei(); // enable global interrupts
higher), then having the PWM signal operate in the same fre-
quency range is obviously not acceptable. The PWM frequency To configure the ISR frequency to 500 Hz, set OCR1A=31;.
can be adjusted by setting certain flags related to the Arduino’s The code that needs to be executed each time the timer ISR
timers. The Arduino Uno has three timers and each controls cer- is called is placed inside a function called ISR with the input
tain aspects of the microcontroller. The challenge is to deter- TIMER1_COMPA_vect, i.e. for prototyping mode
mine which timer controls the analog pin being used and to find
ISR(TIMER1_COMPA_vect)
a timer that will not adversely affect any other needed functional-
{
ity. PWM frequency can be set as high as 16 MHz. The following
digitalWrite(isrPin, HIGH);
two lines set the PWM frequency for pins 5 and 6 to roughly 32
nISR++;
KHz using Timer0. This choice of timer leaves the rest of the
analogWrite(pwmA, v1);
functionality needed for MIL real-time control unaffected.
accel = analogRead(analogPin);
TCCR0A = _BV(COM0A1) | _BV(COM0B1) | fresh = 1;
_BV(WGM00); digitalWrite(isrPin, LOW);
TCCR0B = _BV(CS00); }

Enforcing the real-time execution of the control law is done

using a timer interrupt. The timer settings can be somewhat con-
fusing and the user needs to be careful about which timer is cho-
sen. The system clock on the Arduino runs at 16 MHz. With
the right flag settings, this 16 MHz clock can be divided by a
prescaler of 1024 for ISR usage so that the final ISR frequency
will be
fISR = 16MHz/1024/OCR1A
Placing the following code in the setup function will set
Timer1 ISR to run at 150 Hz:
cli(); // disable global interrupts
TCCR1A = 0; // set entire TCCR1A
// register to 0
Serial Communication
Protocol
There are two key principles that should guide the design of
the communication protocol between the PC and the microcon-
troller. First, data needs to be transmitted as quickly and effi-
ciently as possible. Whenever possible, data should be transmit-
ted as one or two byte integers rather than ASCII strings where
(1) each byte is only one digit. If floating point numbers need to be
transmitted, it may be possible to transmit numerator and denom-
inator integers that can reconstruct the floating point number.
The second principle is that the protocol needs to include
some means of verifying that no data has been lost in transmis-
sion. Some ways to do this include starting each data packet with
a loop index and checking that the loop indices are consecutive
numbers. Users may also want to consider ending each packet
with and certain byte, such as a newline character.

4 Copyright © 2014 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/asmep/81912/ on 05/08/2017 Terms of Use: http://www.asme.org/abo

 Serial Echo Test 30000
expected response
A serial echo test was conducted on the Arduino operating in actual response
prototyping mode. For each iteration through a for loop, the PC 25000
would transmit a loop index and a second number. In a real con-
trols experiment, the second number would represent the voltage 20000

Response
to send to the DC motor H-bridge. The microcontroller would
receive these two numbers as two-byte integers: 15000
nIn = readtwobytes();
v = readtwobytes();
10000

During the next timer interrupt, the microcontroller would 5000

increment its own loop counter and square the second number,
storing the result: 0
0.0 0.2 0.4 0.6 0.8 1.0
ISR(TIMER1_COMPA_vect) Time (sec.)
{ Figure 8. Serial echo test results at 150 Hz. The actual and expected
digitalWrite(isrPin, HIGH); responses for v^2 agree perfectly at each time step.
nISR++;
Out = v*v;
fresh = 1;
1.0
digitalWrite(isrPin, LOW);
}
0.8
Voltage (counts)
Upon leaving the timer interrupt, the microcontroller would
transmit its loop counter, the second number, and the second 0.6 Receive
number squared. Send
if (fresh > 0){ 0.4
fresh = 0;
if (send_ser){ 0.2
digitalWrite(sendPin, HIGH);
SendTwoByteInt(nISR); 0.0
0.250 0.255 0.260 0.265 0.270 0.275 0.280
SendTwoByteInt(v); Time (sec)
SendTwoByteInt(Out);
Figure 9. Plot of the timing signal from LabVIEW for the serial echo test
Serial.write(10);
at 150 Hz. Each receive event completes before the next send event
digitalWrite(sendPin, LOW);
starts.
}
}
There are three tests for whether or not data has been lost the next one, then the serial communication is breaking down.
during this test. First, the loop count transmitted by the micro- Figures 8 and 9 show a successful serial echo test at 150 Hz. The
controller should match that generated by the PC. Second, the Arduino MIL system should be able to operate effectively with a
v echoed back from the microcontroller should match that sent digital update frequency of 150 Hz.
by the PC, but with a one time step delay. Finally, the value Figures 10-11 shows results from a serial echo test at 175
Out echoed back from the microcontroller should match v^2, Hz that includes multiple failures. There are numerous spots
but also with a one time step delay. If any of these tests fail, then where the data echoed back from the microcontroller falls one
the data transmission is not keeping up with the chosen digital extra time step behind. Figure 11 and the inset box in Figure 10
update frequency. zoom in on one failure instance near 0.805 seconds. Figure 11
In addition to capturing the data echoed back from the mi- shows a send event that begins before the corresponding receive
crocontroller and comparing it to what was sent from the PC, event. The inset box of Figure 10 shows the result of the PC
digital pins were toggled on and off to illustrate when the mi- receiving the same data for two time steps in a row.
crocontroller was sending or receiving data. The state of these Figure 12 shows an echo test performed at 200 Hz with even
digital pins was measure using LabVIEW. If the microcontroller more failures. The data echoed back from the microcontroller
does not finish receiving a data packet before it starts to transmit routinely falls an extra time step behind and then stays behind

5 Copyright © 2014 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/asmep/81912/ on 05/08/2017 Terms of Use: http://www.asme.org/abo

 30000 30000
expected response
25000 25000 actual response

20000 20000
Response

Response
15000 0.800 0.805 0.810 15000
10000 10000
5000 expected response 5000
actual response
0
0.0 0.2 0.4 0.6 0.8 1.0 0
Time (sec.) 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7
Time (sec.)
Figure 10. Serial echo test results at 175 Hz.
Figure 12. Serial echo test results at 200 Hz.

1.0 sired closed-loop pole locations. The computational complexity

of the control law may also limit the achievable update frequency.
0.8 The digital update frequency will introduce phase lag associated
with a time delay of one time step. If this phase lag is insignifi-
Voltage (counts)

cant near the crossover frequency of the control system, then the
0.6 Receive update frequency is fast enough.
Send
0.4
Rigid Link Bode and Step Responses
0.2 Figure 13 compares Bode plots from the PSoC MIL system
operating at 500 Hz with the Arduino operating in prototyping
mode at 150 Hz and hybrid mode at 500 Hz for the rigid link
0.0 0.800 0.805 0.810 case. The input to the Bode plot is the command voltage sent
Time (sec) to the H-bridge and the output is the joint angular position from
Figure 11. Plot of the timing signal from LabVIEW for the serial echo test the encoder. Not surprisingly, there is more phase lag for the
at 175 Hz. Arduino in prototyping mode at 150 Hz than for the other two
cases. Using this Bode plot to design a compensator for motor
control will lead to a lower crossover frequency for prototyping
for 10-20 iterations. mode, resulting in a slightly slower closed-loop response.
Unless some means can be found for reducing the latency in Figure 14 shows step responses for the rigid link robot for
the USB-to-serial approach, it appears that the Arduino MIL sys- three different cases: PSoC in prototyping mode at 500 Hz, Ar-
tem can only be used with digital control frequencies up to about duino in prototyping mode at 150 Hz, and Arduino in hybrid
150 Hz in prototyping mode. This seems to raise two questions: mode at 500 Hz. The designs can be made more aggressive as
is 150 Hz fast enough to use on interesting control problems and the phase lag in the system decreases.
can faster update frequencies be achieved using hybrid mode?

Prototyping Step Response Results

Rigid Link System Evaluation
In order to assess whether or not 150 Hz is fast enough
to control systems with interesting dynamics, swept sine tests
where performed on the SFLR. Initially, the flexible link on the
SFLR was replaced with a rigid one. Obviously, the question of
whether or not a certain digital control frequency is fast enough
will always depend on how the control frequency compares to
the frequencies of the dominant poles of the plant and the de-
Figures 15 and 16 show step responses for the SFLR with the
flexible link reinstalled (with and without vibration suppression).
These plots are quite similar to Figures 6 and 7, which was the
primary goal of the initial investigation. The first vibration mode
of the SFLR is near 3 Hz and the second is near 18 Hz. The
vibration suppression schemes aims to suppress the first mode
while avoiding driving the second mode unstable. This appears
to be achievable with a digital control frequency of 150 Hz.

6 Copyright © 2014 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/asmep/81912/ on 05/08/2017 Terms of Use: http://www.asme.org/abo

 30 250
20
10 200
dB Mag.

0
−10 PSoC Proto 500Hz
−20 Arduino Proto 150Hz 150

Voltage (counts)
−30
−40 Arduino Hybrid 500Hz
100 θd
−50 -1
10 100 101 θ
−60 50 ẍtip
−80
−100
Phase (deg.)

−120 0
−140
−160 −50
−180
−200 −100
−220 -1 0.0 0.5 1.0 1.5 2.0 2.5 3.0
10 100 101 Time (sec)
Freq. (Hz)
Figure 15. Step response for the Arduino in prototyping mode (without
Figure 13. Bode plot comparing the PSoC based system operating at
vibration suppression).
500 Hz with the Arduino system operating at 100 and 150 Hz. Both the
PSoC and Arduino are operating in prototyping mode.
250

250 200
Joint Angle θ (Encoder Counts)

150
Voltage (counts)

200
100 θd

θ
150 θd
50 ẍtip
PSoC θ
Arduino Proto θ 0
100 Arduino Hybrid θ
−50
50 −100
0.0 0.5 1.0 1.5 2.0 2.5 3.0
Time (sec)
0 0.0 0.5 1.0 1.5 Figure 16. Step response for the Arduino in prototyping mode (with vi-
Time (sec) bration suppression).
Figure 14. Step responses for the rigid link robot. The PSoC test is
performed in prototyping mode. The PSoC test and the Arduino hybrid controller. This conversion can be a challenging task. In order to
test are performed at 500 Hz. The Arduino prototyping test is performed simplify the task, an Arduino library has been created that imple-
at 150 Hz. ments a digital compensator. The idea is to easily allow a digital
transfer function such as
Final Comparison
Figure 17 compares the step responses for three cases: PSoC v(z) b0 + b1 z−1 + b2 z−2 + · · · + bm z−m
= (2)
in prototyping mode, Arduino in prototyping mode, and Arduino e(z) a0 + a1 z−1 + a2 z−2 + · · · + an z−n
in hybrid mode. The three cases agree fairly well with one an-
other and demonstrate the suitability of the Arduino for real-time to be expressed in C code that is easy to use for transfer functions
feedback control on this particular plant. of any order. At each digital time step, the next output needs to
be calculated:

Hybrid Mode Digital Compensator Class v(k) = (b0 e(k) + b1 e(k − 1) + b2 e(k − 2) + · · · + bm e(k − m)
Hybrid mode requires converting the control logic of the −a1 v(k − 1) − a2 v(k − 2) − · · · − an v(k − n)) /a0
block diagram such as that of Figure 4 to C code for the micro- (3)

7 Copyright © 2014 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/asmep/81912/ on 05/08/2017 Terms of Use: http://www.asme.org/abo

 250 int i;
for(i=len_vect-1; i > 0;i--){
Joint Angle θ (Encoder Counts)

200 vect_in[i]=vect_in[i - 1];//shift

}
vect_in[0] = new_in;
150 }
The code for performing the control calculations for one
100 time step for the MIL system operating in hybrid mode with vi-
bration suppression (as in Figure 4) are shown below:
50 PSoC Proto θ (500 Hz)
Arduino Proto θ (150 Hz) accel = analogRead(analogPin)-511;
Arduino Hyrid θ (500 Hz) u_accel = Ga_comp.calc_out(accel);
0
0.0 0.5 1.0 1.5 2.0
theta_d_hat = theta_d - u_accel;
Time (sec) enc_hold = _EncoderTicks;
e = u_float - enc_hold;
Figure 17. Comparison of step responses with vibration suppression for v_float = theta_comp.calc_out(e);
three cases: PSoC in prototyping mode, Arduino in prototyping mode, v1 = (int) v_float;
and Arduino in hybrid mode. v1 = mysat(v1);
v1 += offset;
analogWrite(pwmA, v1);
In order to create an instance of the digital compensator class,
the user must pass in the vectors of a and b coefficients as well analogRead reads the accelerometer signal and offsets
as vectors that will be used to store the previous n outputs and it by 511 counts to account for the virtual ground. Ga_comp
m inputs. At each digital time step, a new output needs to be refers to the compensator in the acceleration feedback loop Ga .
calculated based on a new input. The elements of the input and u_accel is the output of Ga and the bottom input to the first
output storage vectors needed to be shifted correspondingly: summing junction. theta_d_hat refers to the output of the
first summing junction. enc_hold saves the current encoder
value θ . e refers to the output of the second summing junction.
float dig_comp::calc_out(float new_in){ v_float is the output of the compensator Gθ . v1 is the com-
float new_out = 0.0; mand voltage ultimately sent to the H-bridge after saturation and
shift_array(new_in, _in_vect, a 2.5 V offset are considered. analogWrite sets the PWM
_len_in); duty cycle of the analog output pin pwmA to the value v1. v1
int i; must be an integer between 0 and 255 (8-bit).
for(i=0; i<_len_in; i++){
new_out += _in_vect[i]*_b_vect[i];
} Additional ISR Considerations
for(i=1; i<_len_out; i++){ The PSoC in the MIL system shown in Figure 5 uses a hard-
new_out -= _out_vect[i-1]* ware counter to decode the encoder signal. Because of this, the
_a_vect[i]; only ISR the system uses is the one that enforces the real-time
//note that out_vect hasn’t been execution of the control law. Since this is the only interrupt in
//shifted yet, so the indices the system, the only real constraint on it is that it completes be-
//are off by 1 fore the next digital time step. This same approach did not work
} on the Arduino. The Arduino also uses an interrupt to read the
shift_array(new_out, _out_vect, encoder signal. Initially all control calculations were done in the
_len_out); timer ISR. These calculations take roughly 200 µs to complete.
return new_out; While the plots from these tests looked correct, the author no-
} ticed that the robot link seemed to drift with each test. In order
to diagnose the problem, the encoder signals were also read into
LabVIEW and the signals were analyzed to find the rising edges
void shift_array(float new_in, of the A channel of the encoder. Figure 18 compares encoder
float vect_in[], readings from the Arduino with those from LabVIEW. Clearly,
int len_vect){ the Arduino is missing encoder events. The issue is that while

8 Copyright © 2014 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/asmep/81912/ on 05/08/2017 Terms of Use: http://www.asme.org/abo

 the timer interrupt is performing the control calculations in its 250
ISR, the ISR to update the encoder value is not being serviced.

Joint Angle θ (Encoder Counts)

The encoder is not read until after the timer ISR completes. 200
In order to solve this problem, it must be possible to per-
form the control calculations and send the actuator voltage once
per time step and at hard real-time intervals while still allowing 150
the encoder ISR to run. In order to accomplish this, the control Labview
calculations were moved from the timer ISR to the main Arduino Arduino
100
loop function. The control calculations are placed inside an if
statement so that they only execute if a flag has been set inside the
timer ISR. The timer ISR now has only two lines: it increments 50
the nISR loop counter and it sets the flag to perform the control
calculations. While the control calculations are being performed
in the main loop, they can still be interrupted by the encoder ISR. 0 0.0 0.5 1.0 1.5
Figure 19 shows that this change has lead to perfect agreement Time (sec)
between the Arduino and LabVIEW. Figure 19. Comparison of the encoder measurement from the Arduino
and LabVIEW with a fast ISR for the digital control timer interrupt.
300
culations getting interrupted, the timing between falling edges
Joint Angle θ (Encoder Counts)

250 was not as consistent as the timing between rising edges. The
analogWrite command occurs just before the falling edge of
200 the timing signal.
The results of this timing consistency verification are sum-
Labview
150 marized in Table 1. While the rising edges of the timing square-
Arduino wave show very little variation (top row), the falling edges are
100 not quite as consistent (bottom row). The average for both rising
and falling edges is 99.12 sampling periods. After performing
several tests, it seems repeatable that for the falling edges there
50
is one digital time step (out of roughly 1500) where the timing is
off by roughly +10% and one that is off by roughly -10%. If this
0 0.0 0.5 1.0 1.5 variation in the sending of the analog voltage lead to unaccept-
Time (sec) able performance, the timing of the analog write could be con-
Figure 18. Comparison of the encoder measurement from the Arduino trolled precisely by putting the analogWrite command in the
and LabVIEW. timer ISR. The drawback of this approach is that it would intro-
duce a one time step delay in sending the voltage command (the
voltage that is written in the ISR would be based on calculations
completed during the previous time step). Another alternative
would be to use a dedicated chip such as a hardware counter to
Timing Verification decoder the encoder signals and send the encoder signal to the
Moving the control calculations out of the ISR raises one Arduino via i2 c. The dedicated hardware would add cost and
concern: will the timing between analogWrite commands complexity to the system.
still be maintained accurately (i.e. the sending of the control A final verification of the timing of hybrid mode at 500 Hz
commands to the H-bridge). A digital pin was made to toggle on the Arduino is shown in Figure 20. The lower part of the
up and down when the control calculations begin and end so figure shows that the ISR that responds to encoder signals fires
that the timing could be measured using LabVIEW. The num- multiple times per control update period. The encoder ISR is
ber of LabVIEW samples between the rising and falling edges very brief. The top portion of the figure shows how long it takes
of the square-wave generated by timing signal was used to as- the Arduino to complete the control calculations and then send
sess the consistency of the real-time intervals. The MIL system the data for that time step back to the PC. The control calcula-
was operating at 500 Hz and the LabVIEW sample frequency tions could take 2-3 times longer and still be completed before
was set to 50 kHz, so there should be 100 LabVIEW samples in the end of the time step. The control calculations for the case
between each test. Because of the possibility of the control cal- with accelerometer feedback include two digital compensators,

9 Copyright © 2014 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/asmep/81912/ on 05/08/2017 Terms of Use: http://www.asme.org/abo

 Table 1. Summary of the verification of the timing signal. The digital con-
REFERENCES
trol frequency is designed to be 500 Hz, so there should be 100 periods
[1] Shiakolas, P., and Piyabongkarn, D., 2003. “Development
between rising and falling edges.
of a Real-Time Digital Control System with a Hardware-
Number of 50 kHz sampling periods in-the-Loop Magnetic Levitation Device for Reinforcement
≤ 97 98 99 100 101 ≥ 102 min max of Controls Education”. IEEE Transactions on Education,
46(1), pp. 79–87.
rising 0 60 1215 238 0 0 98 100 [2] Kamis, Z., Topcu, E., and Yuksel, I., 2005. “Computer-
edges
Aided Automatic Control Education With a Real-Time De-
falling 1 189 963 352 7 1 90 109 velopment System”. Computer Applications in Engineer-
edges ing Education, 13(3), pp. 181–191.
[3] Salzmann, C., Gillet, D., and Huguenin, P., 2000. “Intro-
duction to Real-time Control using LabVIEW with an Ap-
plication to Distance Learning”. Int. J. of Engineering Ed-
one that is second order and one that is fourth order.
ucation, 16(5), pp. 372–384.
[4] Bucher, R., and Dozio, L., 2003. “CACSD under RTAI
Linux with RTAI-LAB”. In Fifth Real-Time Linux Work-
1.0 shop, Valencia, Spain.
0.8 [5] Dozio, L., and Mantegazza, P., 2003. “Real time distributed
0.6 control systems using RTAI”. In Object-Oriented Real-
Voltage

Control Calculations
0.4 Send Serial Time Distributed Computing, 2003. Sixth IEEE Interna-
tional Symposium on, IEEE, pp. 11–18.
0.2 [6] Bucher, R., and Balemi, S., 2005. “Scilab/Scicos and Linux
0.0 RTAI - A unified approach”. In Control Applications,
0.150 0.152 0.154 0.156 0.158 2005. CCA 2005. Proceedings of 2005 IEEE Conference
1.0 on, IEEE, pp. 1121–1126.
0.8 [7] Jack, H., and Blauch, A., 2004. “A Modeling and Controls
0.6 Course using Microcontrollers”. In Proceedings of the 2004
Voltage

Encoder ISR ASEE Annual Conference and Exposition.

0.4
0.2
0.0
0.150 0.152 0.154 0.156 0.158
Time (sec.)
Figure 20. Final verification of Arduino timing in hybrid mode at 500 Hz.
Conclusions
This paper investigated whether or not the low-cost, easy-
to-use Arduino microcontroller could be used for real-time feed-
back control. A methodology to investigate the feasibility of any
microcontroller for feedback control applications was presented.
The methodology is based primarily on the combination of serial
echo tests and Bode plots to investigate the effects of digital com-
munication delay on system performance. Additionally, Arduino
specific tips for creating microcontroller-in-the-loop (MIL) feed-
back control systems were also presented. These tips included
how to set the Arduino’s timers for fast PWM and how to setup
a virtual ground for bipolar analog-to-digital conversion.
[8] Jack, H., and Blauch, A., 2005. “A Modeling and Controls
Course using Microcontrollers”. In Proceedings of the 2005
ASEE Annual Conference and Exposition.
[9] Milam, W., 1993. “A Distributed Computing Approach to
Rapid Prototyping for Embedded Controllers”. In Circuits
and Systems, 1993., Proceedings of the 36th Midwest Sym-
posium on, pp. 1155–1158.
[10] Rebeschiess, S., 1999. “MIRCOS-Microcontroller-Based
Real Time Control System Toolbox for Use with Mat-
lab/Simulink”. In Computer Aided Control System Design,
1999. Proceedings of the 1999 IEEE International Sympo-
sium on, pp. 267–272.
[11] Koehler, C., Mayer, A., and Herkersdorf, A., 2008. “Chip
Hardware-in-the-Loop Simulation (CHILS)-Embedding
Microcontroller Hardware in Simulation”. In Proceedings
of the 19th IASTED International Conference, Vol. 620,
pp. 297–302.
[12] Krauss, R. W., and Croxell, J. R., 2012. “A Low-Cost
Microcontroller-in-the-Loop Platform for Controls Educa-
tion”. In American Control Conference, 2012. Proceedings
of the 2012, IEEE.

10 Copyright © 2014 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/pdfaccess.ashx?url=/data/conferences/asmep/81912/ on 05/08/2017 Terms of Use: http://www.asme.org/abo