ME 481 Project 2

Bailey Ryan and Roslyn VanSickle

Introduction 3

Design Specifications 3

Controller Simulation 4

Procedure for modification of move_sphero.py 5

Procedure for testing reference tracking design 5

Error Signal Plots for reference tracking 6

Procedure for testing disturbance rejection design 6

Error Signal Plots for disturbance rejection 7

Introduction
The purpose of this project was to design a controller that allows the Sphero to move at
0.5 m/s for 1 second, followed by 1.0 m/s for 1 second in a continuous pulse. First we
designed a model of a time-domain PID controller in order to identify the controller gains
required to achieve the desired specifications. Using this model we were able to
simulate the closed-loop system and determine whether the output model velocity
tracked the reference velocity signal. The PID controller gains were then improved to
provide accurate signal tracking. The controller gains were then changed in order to be
implemented in the Sphero system and account for the variable conditions caused by
the Sphero’s components and environment.

Design Specifications
The transfer function for the plant is a first order system as follows:

The transfer function of the system takes an input of command velocity (cmd_vel) in
cm/s and reports an output velocity in m/s. Since this system is first order it has a
transient specification of a time constant. This value was found by rearranging the
transfer function to the form below.

This means that the Sphero takes 0.22205 seconds to reach 63.21% of its desired
velocity. When the system is subjected to the pulse input as mentioned above, it
produces the following output. This is not an ideal output as one can see the system is
slow to respond and there is a constant error present.
This specification is most likely satisfactory for the target user of the sphero, which is a
child. However, from an engineering standpoint this time delay is too great to be used in
specific control circumstances. An example of such is if the user would like the sphero
to cover a certain distance in a specific time, this may not be easily achieved due to the
delay and variation in speed. Another circumstance where such a delay would be
unacceptable is in the case of autonomous vehicles, where any delay in acceleration or
deceleration could cause an accident.

Changing these specifications will create a more robust design that is able to accurately
track a reference and reject disturbances. These specifications can be tuned to achieve
better reference tracking or disturbance rejection, based on the limitations of the
physical system used.

This transient response of the open loop is not satisfactory from an engineering
perspective. The response does not accurately reflect the reference signal, there is a
steady state error, and the rise time and steady state error can be improved upon. While
the system is a first order system it can be analysed as an overdamped second order
system. In which case the rise time, settling time, and maximum overshoot are the
specifications that can be changed for the system. The most important specification to
control for the objective of reference tracking is the settling time and rise time. The least
important specification is the maximum overshoot because it can be corrected with
damping terms in the controller.
To accurately track the reference pulse signal the specifications for an improved sphero
include a rise time of less than 0.1 second. This is a reasonable rise time as 0.1 second
is 10% of each pulse period. The settling time must also be less than 1 second, as that
is the pulse period and the signal must settle in the prescribed time. Since the system
acts as an overdamped second order system a damping coefficient greater than 1 is
reasonable. If this is the case a settling time of less than 0.14 seconds can be achieved.
Lastly a peak overshoot of 0 would be the most improved Sphero system, however this
may not be able to be achieved.

Controller Simulation
To achieve the specifications mentioned above a controller must be added. Since the system is
an overdamped second order system, with a step input the controller must place a pole at zero
to achieve a steady state error of zero. This implies that the controller must have an integral
term. A proportional controller would also assist in decreasing the rise time of the controlled
response. While a derivative term can be added to the controller, it is not necessary in this case,
as the system can be adequately controlled with a PI controller.

A Simulink diagram was used to theoretically test the coefficients of a PID controller. ​This
simulation is showing a model of the Sphero system with a PID controller and feedback
loop. In the first iteration of testing the following specifications were attempted to be
achieved by the system, a rise time of 0.1 seconds and settling time of 0.14 seconds.
The coefficients of Kp and Ki were determined by comparing the characteristic equation
of the system above with the standard form of the characteristic equation of a second
order system. The values of ω​n​ and ζ were determined by the desired specifications.
The proportional gain indicates that there is an proportional error between the reference
signal and the output signal of 1000, while the integral gain is increased with the
decrease proportional gain to decrease the residual error term. The response to the
controller with the above coefficients can be seen below. While this meets the minimum
specification conditions, it is not the most ideal controller and more iterations of testing
were completed.

In the second iteration of testing the PI controller gains were increased extremely to
observe the effect of these values on the steady state error of the system and the rise
time. A proportional gain of 1000 and an integral gain of 2000 were selected. As
expected this system has excellent reference tracking and a very quick rise time, as
seen in the graph below, it may not be feasible for the physical constraints of our
system.

Since the control system above is not feasible for our physical system, a third iteration
was completed choosing coefficients for Ki and Kp that would give the best results for
the most important specifications of rise time and settling time. The value for Kp was
equal to 250 and Ki was equal to 250 as well. The result of this controller can be seen in
the graph below.
Procedure for modification of move_sphero.py
1. Locate robot_move class within move_sphero.py.
2. Create a ROS publisher to publish cmd_vel ROS topic.
a. Initialize ‘self’ object.
b. Create variable self.cmd_vel and set it equal to the Twist function.
c. Set self.pub equal to rospy.Publisher with the input cmd_vel, using the
Twist function, and setting the queue_size equal to 10.
3. Define a callback vector to read the data from the imported function Odometry.
4. Create a subscriber to collect the data from Odometry.
5. Controller implementation into the code:

The following calculation was integrated into our code to act as the controller

Since the sphero has a sampling rate of 50 Hz and the value of Ki_bar is equal to
Ki times delta t, the value of Ki_bar is equal to 50. The Esum value is then
calculated by adding the error experienced by the system. This can be further
analyzed in the attached code.

Procedure for testing reference tracking design

A PI controller was implemented and both proportional and integral values were varied
from the simulation values to create an accurate controller given the variability in
Sphero components. The final proportional and integral terms were both 250. These
values were tested by reading the output x velocity while running the control sphero
script. These tests were conducted on a flat, smooth surface provided by the
engineering department. Once accurate PI values were determined the control sphero
script was run with rosbag record -a running in the background. This data was then
converted to csv form and used to create the plots shown below.

The data showed that the simulation does not accurately simulate the Sphero system,
this is believed to be caused by environmental factors, component variation, and
infrequent data collection that could not be accounted for in the simulation, ie. the
surface not being perfectly flat, Sphero not able to perform at full charge, variations in
friction between the surface of the floor and the surface of the Sphero, and small testing
area. To account for these things it is recommended that testing be done in a controlled
area with a reasonably large, flat, smooth surface with the data collection rate increased
and testing durations extended. The testing duration could be increased by disengaging
the Sphero sensor that indicates orientation so that any large, uninterrupted surface can
be used no matter the shape or orientation.

Error Signal Plots for reference tracking

Figure 1: Reference tracking error signal.

Figure 1 shows the error signal generated by the difference in the output x velocity and
the reference velocity over time while the Sphero is traveling over a flat surface. The
light blue line is showing the response trend. This shows that the controller has a
degree of overshoot in correcting the velocity. The controller reacts to a large positive
error signal by causing a large negative error signal. This error is likely generated by the
lack of friction, or grip, between the Sphero and the surface it is rolling on. This can be
minimized by increasing the data collection rate and implementing a filter to reduce the
error caused by delayed data collection.

Procedure for testing disturbance rejection design

After the PI controller values were determined the system was then tested using a
ramped area which connects Sloan Hall to Dana Hall. The control sphero script was
again run with the rosbag record script running in the background. That data was again
converted to csv form and evaluated. That data was compared to data taken in the
same area using the control sphero script without a controller to simulate an open-loop
system. As expected and seen through observation, the PI controlled Sphero ascended
the ramp at a much faster rate than the uncontrolled Sphero.

Error Signal Plots for disturbance rejection

Figure 2: Disturbance rejection error signal.

Figure 2 shows the the error signal generated by the difference between the output x
velocity and the provided input velocity while the Sphero is traveling up an inclined
ramp. The light blues line shows the response trend. It can be observed that the error
signal generated is affected by the incline as well as surface slip. It was observed during
testing that the Sphero’s velocity increased greatly in order to overcome the incline of
about 10° and counteract the effects of the Sphero slipping down the incline.
Figure 3: Open-loop disturbance rejection error signal.

Figure 3 shows the open-loop error signal generated by the Sphero rolling up an incline.
This exhibits a steady error signal generated without the controller implementing
changes in velocity to overcome the error caused by the ramp. During testing it was
observed that the Sphero ascended the ramp at a significantly slower speed without the
controller to counteract the incline angle. The speed of 0.043 m/s was low enough that
the Sphero easily rolled back down the ramp, while with the controller in use, the
Sphero was able to overcome the ramp’s angle.

Python Script
The following is the python script used in this project: