1. Introduction
The Sphero Project commenced on February 21, 2016 as that was the day where I had
downloaded the Sphero Matlab library along with the A* algorithm. Once this was done, I
needed to understand how to connect Sphero and how to essentially “talk” to the robot; in other
words, what commands allowed the robot to move, stop, and change directions. The final goal of
this project was to convert A* to commands that the robot could understand; as a result, the robot
would be able to traverse any path within a 7 by 15 grid as shown in Figure 1.
Sphero
First the Code for sphero checks to see if Sphero is connected to the comp via Bluetooth.
Once connected, it changes colors from red, green, to blue. Once that is done, the program
checks to see if sphero has stabilized--sphero wobbles, then pauses--then it becomes motionless.
Once it was connected to the computer, the coding process began. I noticed that the command,
roll(x,y)—where x and y are 2 arbitrary numbers, caused the robot to move in a line. When I
initially started to code Sphero, I assumed that the roll(x, y) command involved coordinate
points, however, as the coding continued, I realized that it was angle and speed. As a result the
roll command can be written in the following manner roll(angle, speed); in this case, the
parameter angle takes a number between -360 and 360 degrees whereas the parameter speed
takes a number between -255 and 255. Whenever the roll command is given, the robot rotates
based on the angle value, then moves in a straight line at a rate based on the speed value. For
instance, if the command roll(90,70), then the robot rotates 90 degrees and rolls at a rate of 70 in
a straight line. While inputting a degree value, it is important to note that a small black square on
the robot indicates the front of robot; the reason for this note is so that the positive direction and
negative direction can be easily seen. If the robot needs to be rotated to the right, then a negative
angle needs to be used, while a positive angle is required if the robot needs to be turned to the
left.
Another command that is incredibly important is the pause(second) command—where
seconds is a number between 1 and 1000. Even though it doesn’t seem like much of a command,
it helps the robot change directions in a nice fashion. This command makes Sphero stop for
certain amount of seconds. For instance, if sphero was programmed to roll in an L, it would need
to first roll forward, then turn either left or right; the code would look something like the
following: roll(90,70) roll(180,70). The problem with this, however, is that it does not give the
robot time to pause during the turn. As a result, it will just curve and the robot will make a U
rather than an L. To fix this situation, the pause command needs to be used between the roll()
commands: roll(90, 70) pause(2) roll(180,70). This way the robot has sufficient time to perform
1 command, take a small break, and then turn to perform the next command. By using this
command, the robot can be programmed to make any number of turns. Once the knowledge for
programming the robot has been acquired, the A* algorithm can be used to program the robot so
that it can run any kind path.

2. A* Algorithm
Figure 1: A* Demo
In order to use A*, it is imperative to understand what it does. Basically, the algorithm
asks the user for the initial position, final position and it makes the shortest path that connects the
two locations. The algorithm assigns each block a value and based off the sum of those values,
an Optimal Path is created. In the Matlab A* code, a value of -1 was assigned to an obstacle, a
value of 0 was assigned to the target, a value of 1 was assigned to the robot, and a value of 2 was
assigned to an empty space. The algorithm recorded the starting x and y coordinates, the target’s
x and y coordinates, and the coordinates of each block the robot traversed. Once the robot
reached the target, all of the x and y coordinates were appended to an array called Optimal_path.
In figure 2, the purple circle is the starting position, the blue circle is the target, the red circles are
the obstacles, and the blue line is Optimal_path. Once this is known, the array can then be used
to write commands for Sphero.

3. A* Translated
Figure 2: Sphero Code via A*
The code in Figure 2 takes the array generated by the A* algorithm known as
Optimal_path and converts it into sphero commands. It is important to keep in mind that the first
column of Optimal_path represents the x coordinate of each block over which Sphero traverses,
while the second column represents the y coordinate of each block over which Sphero traverses.
First, the arrays are generated; this way the values can be saved to these arrays. The value, x0,
represents the first coordinate pair in the matrix, x1 represents the subsequent coordinate pairs,
xydifference represents the distance between the each block, and angle represents the angle
caused by the distances. After that comes the first for loop.
The index of this loop is from 2 to the length of the Optimal_path matrix. The reason why
it starts at 2 is because the first entry is already taken into account with x0. This loop takes the
first coordinate pair and subtracts it from the second coordinate pair, and the value that is
generated is the distance between the coordinate pairs. Once this value is gathered, it is then
stored into the xydifference matrix. After this, the loop moves through the Optimal_path and

4. makes the second coordinate pair as the original pair . The Matlab trig function atan2(y,
x) takes in a y value, an x value and takes the tangent to determine the angle. Now, the first
column in the xydifference array is the difference in the x-direction, while the second column is
the difference in the y-direction. As a result the loop cycles through the xydifference array and
calculates the tangent angle for each coordinate. It then stores each angle in the allocated array
called angle[ ]. Because the indexing of the loop starts at 2, I had to brute force the first angle in.
The problem with this, however, is that the atan2() spits out values in radians instead of
spitting out values in degrees. Sphero only reads degrees, so these values must be converted to
degrees, hence the second loop. The indexing in this loop is the same as the indexing in the first
loop, but there is a minor change. Because the angle regarding the first coordinate is 0 radians, it
will also be 0 degrees—0 radians = 0 degrees. As a result, the first value in the angle[ ] array can
be ignored. Each subsequent number is then multiplied by
180
𝜋
; the new values replace the old
values in the very same array. Now that the correct type of angle is determined, Sphero can now
be addressed.
In this case, the only array that is of concern is the angle[ ] array as that has the only
information Sphero can use. The indexing in this loop is different as it starts from 1 rather than
starting from 2. This loop traverses the angle[ ] array and over each iteration the robot rolls a
certain distance, then pauses for 3 seconds. The key command in this case is the pause(3). This is
because if the command was non-existent, then Sphero would just roll in curves rather than
rolling in straight lines.
Possible Trouble
Though the robot can be programmed to do a certain task, it has its own nuances. When
dealing with technology, the troubleshooting for a certain problem is relatively simple, however,
this was not the case with Sphero. The problems that occurred are as follows: connecting via
Bluetooth, functionality of the robot, and the response to commands.
The first of which involves the connection between Sphero and the computer. Each
Sphero comes with its own unique name; in this case, the name of the Sphero is “Sphero-RWG”.
Now, in order to find this name, the robot must be connected to the computer via Bluetooth.
Then, the connect command is entered and the robot is usually connected, usually being the key
word. There would be times where the robot would not connect to the computer and as a result,
the computer would need to be restarted.
Another problem involves the functionality of the robot. When a command is entered for
Sphero, the robot is expected to perform the command. However, the robot will sometimes fail to
execute the task. For example, when the roll() command was used, Sphero is supposed to roll;
however, sometimes this would not be the case. Sphero would be in idle and would not roll.
This was extremely irritating because the troubleshooting was also a headache. With any piece of
electronics the best way to troubleshoot involves restarting the device; however, this is not the
case with Sphero. When Sphero was restarted, it would execute the command the first time, but
not subsequent times. As a result, the robot either needed to be restarted, or it needed to be
charged.
The final problem involved Sphero’s response to commands. For instance, when Sphero
was told to roll in an L, it was given two roll commands with the same exact speed. In other
words, the robot was told to roll in a line at a certain speed, then turn and roll at the exact same

5. speed. However, this was not the case. The robot rolled at different speeds and as a result, the
distance rolled before and after the turn was not the same. I was not able to find a solution, as it
was unpredictable. What this means is that sometimes the robot would work just fine, whereas
other times the robot wouldn’t seem to cooperate at all. The worst aspect of this problem was the
fact that restarting either Matlab or the computer, would only be a temporary fix.
Conclusion
Prior to starting this project, I was still learning Matlab and thus, I was still a novice.
However, once I started to interact with Sphero, I started to become more accustomed to the
language. In general, I had to figure out how to connect the robot to the computer and download
the necessary files. Then, I had to understand what commands Sphero used. After that, I had to
comprehend the logistics of the A* algorithm. The last step was to combine the acquired
knowledge and produce a code that would allow the robot to run any desired path.
With all of that being said, there is one thing that could be attempted in the future.
Assuming the starting position is a corner of a room, then the robot could be dropped at a
random spot in the room and it would roll itself to the allocated corner. One possible way to do
this would be to make use of the accelerometer, collisiondetection() function. This way the
accelerometer can be calibrated to record the acceleration at the point of contact; as a result, the
collisiondetection() function would then be able to use those values and make the robot stop once
it hit a surface.