Nayan Patel

UNIVERSI
TY OF
DETROIT
MERCY

Ryan Welsh

Theodore Chase

MICROCONTROLLER DESIGN
REPORT

Microcontroller Design Project

Nayan Patel
Ryan Welsh
Theodore Chase
--------------------------------------------------------------------------------------------------------------------Project Overview
The primary task of this project was to program the Pioneer 3DX to be able to
wander randomly and avoid obstacles that may be present in a given space. This
involves developing an algorithm that allows the robot to assess the present
situation and respond in an effective manner. This is accomplished by the use of
sonar sensors.
Sub-tasks include reading and processing unique color blocks from the Pixy
Camera while driving autonomously. The algorithm for this contains switching of
tasks from a wander mode to a color following mode. The Pixy Cameras goal is to
look for color codes which mark a door and drive towards it. If the door is open, the
robot will proceed into the next room. Otherwise, the robot will wait for the door to
open.
Task Requirements
Developing an algorithm that enables the robot to avoid obstacles requires
processing data recognized in the surrounding environment. The eight sonar
sensors send array of data to the HS12 processor through serial communication.
Based on the value of data in each array index, the robot can determine if an object
is near and where the object is in relation to the center of the robot.
The Pixy Camera enable the robot to follow a moving color or drive to the
location of a stationary color. The cameras view is similar to a coordinate system
having X and Y values which correspond to width and height respectively. An
objects location in the view frame can be recognized. The Pixy Camera sends an
array of data to the HS12 using Serial Peripheral Interface communication. Based
on the data in the array indexes that correspond to the objects location in the view
frame, the robot will drive in the direction of the selected color.

Our Pixy Camera was responsible for the main goal of this project: locate and
exit a door. This is a complex task which also requires obstacle avoidance for safe
driving. The camera will locate a color signature, and drive toward it. We will
assume our color code is located on the left side of a door-way. Upon reaching the
door, if it is open than continue through. Otherwise, our robot will wait until the door
is opened. When opened, the robot will drive through the doorway.

Microcontroller Design Project

Nayan Patel
Ryan Welsh
Theodore Chase
---------------------------------------------------------------------------------------------------------------------

Hardware Overview
I.

Sonars

Pioneer 3DX Sensors

Figure 1: Our Pioneer Robot -

Labeled

Sensors

The sonars (see Figure 1) were used to steer the Pioneer 3DX
away from obstacles that the robot may encounter. We
developed many different methods of using the sonars in an
attempt to derive a smooth, consistent avoidance system.
1. Initial Plan
At first, we believed that the data being read from our SCI Buffer
coordinated directly to the distance from the sonar. Our method for
avoidance was to locate obstacles while they were still far away from the
robot. Our search range was three meters from the front sensors (sonars
2,3,4 and 5), and roughly a half meter from the side sensors (sonars 0,1 and
6,7).
After reading the sonars, we developed nested if statement which
separated the sonars into a subsections for the front, left, right, front-left and
front-right. Depending on which sonars were reading objects, we immediately
sent a new velocity for our robots path. For example, if an object was found
to be in the front-left section of the robot, a quick speed change would occur
to dodge the obstacle. In contrast, if the left section of the robot found an
object, the speed change would be less drastic because less turning is
necessary to avoid the obstacle.
2. Revisions

Microcontroller Design Project

Nayan Patel
Ryan Welsh
Theodore Chase
--------------------------------------------------------------------------------------------------------------------We realized that many of our calculations were inaccurate, as our robot
would change direction drastically and, at times, for seemingly no reason.
Our first realization was that our buffer did not read distances from the
sonars, rather the center of the robot. Realizing this allowed for recalculation
of distances, creating more accurate decision-making.
Our side sensors were also recognizing obstacles that did not exist. We
attributed this to the narrow walls of the hallway we were using and realized
that we didnt need to read far from our sensors 0 and 7. In fact, we changed
from measuring half a meter to around half

a foot away from our outermost sensors. This increased the smoothness of
our obstacle avoidance system, minimizing the occurrence of random and
unnecessary avoidances.
When approaching our control algorithm, we realized that a flag-style
system may be better for adding more varying control. We developed a
function to set obstacle flags (either obstacleLeft, obstacleRight,
obstacleLeft_Front, obstacleRight_Front, and/or obstacleFront). The definition
of our flags is determined by the location of the sensors (see Figure 2, below).
A flag is set when any single sensor in a subsection breaks the threshold
distance for its group. At first, our new method was found to work much
better as we were able to make specific cases if multiple flags were set.
However, we realized that we took on too much complexity when creating the
obstacleRight_Front and obstacleLeft_Front flags. After removing these and
lowering the sensor distance threshold, our driving algorithm smoothed
drastically.

Key
ObstacleRight =
ObstacleRight_Front =
ObstacleLeft =
ObstacleLeft_Front =
ObstacleFront =

Figure 2: Pioneer 3DX Sonar Arrangement and Flag Definitions Based on Location

Microcontroller Design Project

Nayan Patel
Ryan Welsh
Theodore Chase
--------------------------------------------------------------------------------------------------------------------3. Difficulties
Reading from our sonars was perhaps the most challenging task we had to
face in this project. At first, debugging was made impossible due to
hardware issues. We hadnt realized that our SCI cable was broken, thus not
communicating. To test this, we attempted to read data from our SCI Buffer
using another groups cable. After this worked, we quickly received a
replacement.
Our original method for reading the sonars was also very crude. At first,
every 10 milliseconds we were checking our SCI Buffer for new data.
However, after reading through the datasheet for the Pioneer 3DX, we
realized we were reading far too often. The default time to poll a sensor is 40
milliseconds, so to read all 8 sensors takes 320

milliseconds. We realized that we were reading old data multiple times,

which takes up processing time and uses unnecessary data.
When developing a response system, we originally made abrupt and
aggressive turns. This avoided objects well, but made the robot look very
stiff when moving. To avoid this issue, we are attempting to move from a
linear, single-variable turn to one which incorporates a turn multiplier. This
turn multiplier, in our theory, will be developed in a separate function
depending on relative distances the object is from the robot.
In general, when the object is in close proximity, overall speed is lowered
and the difference between wheel speeds is raised. This makes a tighter
turn. When the object being read is far, speed is raised and the difference
between wheel speeds is lowered. This allows for a slight correction by our
robot, rather than an unnecessary abrupt change.
4. Limitations
The biggest sensor limitation is the rate at which we receive data. Every 40
ms (by default) a single sensor is updated. However, each poll reads 2 or 3
sensors, so times in between new data would range from 80 120 ms. Thus,
old code was constantly being read into our SCI Buffer because we were
polling too frequently. By lowering the reading consistency, we were able to
save on power, processing time, and make a smooth transition when
encountering an obstacle.
Another issue with our sensors was reading inexistent objects. At first, we
believed that our sonars were malfunctioning or that there was too much
4

Microcontroller Design Project

Nayan Patel
Ryan Welsh
Theodore Chase
--------------------------------------------------------------------------------------------------------------------noise in our signal. We attempted to account for this by raising the distances
we checked our sensor data at. To our surprise, this did not solve our issue.
We realized that, because we were reading old data consistently, that the
robot would make movements based off flags which were already set but
have been handled.
5. Capabilities
The Pioneer 3DX sonars allow for full 180 degree vision of up to five meters.
The data is sent to an SCI Buffer which reads an array containing either 46 or
49 bytes of data, depending if two or three sensors were read. By default,
every 40ms a sensor is polled. We changed this to 50ms, because testing
showed a more smooth transition from normal movement to obstacle
avoidance.

II.

Pixy Camera
1. Initial Plan
The Pixy Camera enables the robot to recognize a color signature and sends
data to the HS12 using full duplex SPI communication. The color will indicate the
location of a door that the robot must reach. Our initial plan does not require full
duplex communication because we decided that we did not need to use the pan
and tilt function on the Pixy Camera. This plan would send the value in the index
that corresponds to the X value in the view frame from the data packets.
Once the data is received, the processor compares the value to X center of
the view frame, and the robot will drive accordingly. If the data indicates that
the object is within the designated range of left view, the robot will drive left,
sending lower values to the left motor than the right. If the object is in the
center range, both motors receive the same velocities to drive straight. If the
object x coordinate falls into the right view range, the robot will drive right,
sending lower velocities to the right motor than the left motor to turn right. This
is a basic step function that we created to have the robot follow a selected
object.
2. Revisions
Revisions will and have be made in this code that will send velocities to the
robot to turn based on how far away from the X center of the view frame. This
would be a linear function that would increase the precision of the robots ability
5

Microcontroller Design Project

Nayan Patel
Ryan Welsh
Theodore Chase
--------------------------------------------------------------------------------------------------------------------to follow an object. Other than Pixy Cam initialization, the HS12 is not sending
data to the Pixy Cam. Revisions can be made that makes use of the full duplex
communication.
While the Pixy Cam sends data to the HS12, the detected objects X
coordinate can be evaluated by the HS12 and send data to the Pixy Cams
panning servo motor in the direction of the object. This will increase the view of
the Pixy Camera and precision of the
robots ability to follow a color. Because SPI communication is full duplex, the
HS12 can send data to the Pixy Cams panning servo motor as it is receiving
data about the object.
When an object is not in view, the HS12 will send data to the panning servo
motor to rotate for its entire range in both directions, over doubling the Pixy
Cams range to search for an object. The Pixy Cam updates the data packets at
a faster rate than can be processed by the HS12. We plan to overcome this by
using the PLL to increase the crystal frequency to 24 MHz and E-Clock to 12 MHz
3. Difficulties
Originally, the Pixy Cam was operating off of 5 volts from the SPI
communication wires attached to the primary I/O port on the HS12. This was
causing odd behavior in the servo motors: the motors were moving while they
were not being sent movements commands. After looking at the datasheet for
our Pixy Cam, we realized that 6-10V are necessary to operate this device. Our
robot has a 12 volt output that is used to power the Pixy Camera,
resulting in wasted power. Moving the power supplied to the Pixy Cam from the
HS12 to the robots 12 volt power supply fixed the problem of the moving servo
motors.
4. Limitations
With our Pixy Camera, the biggest issue was the amount of data we were
receiving. The Pixy Camera updates data at a rate of 50 frames per second. For
our use, this was far more than we had expected. To be able to handle this
amount of data, we worried that our robots responses would lag because of too
much time going into retrieving data from the Pixy Camera.
5. Capabilities
The Pixy Cameras pan and tilt function allows for 255 of visibility. The Pixy
can recognize up to 7 different preset or preconfigured color signatures. These
signatures can be changed in code, or set prior to running our robot. The rate at
which our camera can update data is remarkable. As stated in our limitations
section (above), we believe that this rate is unnecessary for our task, and would
only lead to a lagging response from our Pioneer 3DX.

III.

XBEE:
6

Microcontroller Design Project

Nayan Patel
Ryan Welsh
Theodore Chase
--------------------------------------------------------------------------------------------------------------------1. Requirements
The requirements for the Xbee232 module were to connect wirelessly to the
TechArts HS12 board and send specific commands to the HS12 board. This was
to be accomplished by connecting the Xbee232 router to the PC and connecting
the Xbee232 Coordinator to the Serial port on the HS12 Board.
2. Initial Plan
The initial plans set aside for the Xbee232 were to read schematics and
understand the power requirements and communication pinout. The plans also
required an understanding of the communication protocol between the HS12
and the Xbee232 was key. In addition, the software tool (XCTU) to setup the
Xbee232 modules was necessary. We also designed a code and created
function packets on the XCTU to send and receive commands. We used
Hexadecimal data packets to activate our function in the main code.
3. Difficulties
The initial problem with the Xbee232 began with a lack of serial port to
connect on the HS12 as the SCI0 port was occupied by the robot
communication. To resolve this problem, jumpers to the SCI communication
port were cut out and these jumpers were used to connect using TTL with the
HS12. In addition, a Female-Female 9 pin serial connector was made to connect
the Xbee232 to the PC.
Setting up communication between the router and the coordinator
presented issues that led to multiple stages of troubleshooting. During
troubleshooting, an adapter from another group was used and the
communication setup worked without much difficulty this led to the
conclusion that the adaptor was defective. All the other design and hardware
concepts were easy to understand using the schematics and the XCTU software
tool.
4. Revisions
There were two revisions made to the Xbee232 module: (1) the jumped
Xbee232 module was replaced back while the 4-pin SCI1 port on the HS12 was
modified for use and (2) the PC Xbee232 adapter was replaced with compatible
USB instead of a 9-pin female-female SCI.
5. Capabilities and Limitations
Xbee232 is a great wireless tool for short range communication. It can be
used to communicate at approximately 300Ft range without any issues. The

Microcontroller Design Project

Nayan Patel
Ryan Welsh
Theodore Chase
--------------------------------------------------------------------------------------------------------------------device has capabilities of communication at 921K Baud, which is quite
impressive as well.

Design Specifications
MC9S12DP512:

Figure 3: Our HS12 Microcontroller within its Housing Container

The HS12 processor runs optimally at 12 volts and is protected against

reverse polarity.
The board uses two jumpers to enable four different modes: Flash, JMP-EE,
Pod, and Bootload. We use flash and pod modes only.
The board has a 16 MHz crystal allowing for an 8MHz E-clock
The board has two dedicated serial ports. One is a 9 pin female RS232 that
connects to the robot. The other is a 4 pin RS232 interface that connects to
the XBEE coordinator.
There are two designated 50 pin I/O ports. The primary port (H1) is used for
the SPI communication with the Pixy Camera. The secondary port (H2) is
used to power the XBEE coordinator.
8

Microcontroller Design Project

Nayan Patel
Ryan Welsh
Theodore Chase
---------------------------------------------------------------------------------------------------------------------

Pixy Camera:

Figure 4: Our Pixy Camera

The Pixy Camera communicates using Serial Peripheral Interface with Master
Out Slave In (Mosi) and Master In Slave Out (Miso) to send data
The Mosi and Miso connections are made at the H1 primary digital I/O port on
the HS12.

The Pixy Camera can run on 5 volts from the SPI communication off of the
HS12 board or can receive 6-10 volts through the cameras main power
supply.

XBEE Modules:

Figure 5: Xbee Receiver

Figure 6: Xbee Transmitter

There are two XBEE modules: XBEE router (connects to the computer) and
XBEE coordinator (connects to the HS12).
The XBEE modules are a wireless serial communication tool. The
coordinator is connected to the 4 pin SCI1 RS232 port. The router is
connected to the computer using a 9 pin RS232 serial cable.
XCTU software tool is used to pair these modules and communicate
between them.
9

Microcontroller Design Project

Nayan Patel
Ryan Welsh
Theodore Chase
--------------------------------------------------------------------------------------------------------------------

The XBEE modules themselves run at 3.3 which is regulated from the 5
volts given by their adaptors.

Other Problems Encountered

Our method to overcome challenges changed drastically as we became more
experienced developers. At first, crude guess and check strategies made progress
difficult. As we realized the complexity of our code and how to debug the varying
issues that developed (lack of communication between I/O, unexpected
results/actions, etc.), we looked to hardware as the issue. We noticed multiple
connections were made with broken wiring, or adapters were not made correctly.
The last issue we encountered was our processor burning out. By mistake, we
connected our power in jumpers to the output of the HS12. This was a cataclysmic
error which cost us a couple of hours to work on this project. From this, we learned
to ensure that connections are properly made prior to powering the microcontroller.
This will save on resources and time.

Workload Distribution
20% Design: Nayan (25%), Ted (30%), Ryan (45%)
35% Hardware Implementation: Nayan (50%), Ted (35%), Ryan (15%)
35% Software Implementation: Nayan (25%), Ted (30%), Ryan (45%)
10% Report Writing: Nayan (30%), Ted (40%), Ryan (30%)

Conclusion
Although challenging, this project allowed us to enhance our knowledge with
microcontrollers. This field is quickly growing and the skills we gained through this
design process will greatly affect our professional careers in the future. Through
hardships arose lessons which taught us more efficient methods for developing,
testing, and implementing software and hardware configurations.
The idea for this project was developed well by the professors and TA.
However, there were minute issues that could have been overcome easily.
Throughout the term, our TA was unavailable for much questioning. Granted, being
10

Microcontroller Design Project

Nayan Patel
Ryan Welsh
Theodore Chase
--------------------------------------------------------------------------------------------------------------------in a graduate year of college occupies much of ones time. Overall, the assistance of
a TA for questioning throughout the day would have made this projects goals much
easier to implement.
On the other hand, there were many things done exceptionally well.
Hardware, for one, was never an issue even after two processors and a Pixy Camera
burnt out. It was obvious to our group that the professor and TA had thought out
this possibility and prepared well for it. Had this not been done, multiple groups
would not have been able to finish their projects.
A suggestion we would give to future students in this course would be to
organize your work effectively. A relative plan should be derived early in the
semester, which is something our group somewhat lacked. Work is hard to come by
without a set list of goals and tasks that are necessary to complete. Lastly,
communication with your professor and TA is key to success. Realize that they are
there to assist you through this project, even though at times that may not seem
like the case. Also remember the power of subjective grading, which is obviously
something we overlooked in that last sentence.

11