intro to microcontrollers - final project design report

12/10/2015Nayan Patel Ryan Welsh Theodore Chase

University of Detroit Mercy Microcontroller Design Report

Microcontroller Design ProjectNayan 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 Camera’s 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 camera’s view is similar to a coordinate system having X and Y values which correspond to width and height respectively. An object’s 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 object’s 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.

1

Pioneer 3DX Sensors


Hardware Overview

I. Sonars

Figure 1: Our Pioneer Robot - Sensors Labeled

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 robot’s 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

2

Key

ObstacleRight = ObstacleRight_Front = ObstacleLeft =ObstacleLeft_Front = ObstacleFront =


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 didn’t 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.

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

3


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 hadn’t realized that our SCI cable was broken, thus not communicating. To test this, we attempted to read data from our SCI Buffer using another group’s 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. LimitationsThe 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


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. CapabilitiesThe 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 Camera1. 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

5


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 robot’s ability 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 object’s X coordinate can be evaluated by the HS12 and send data to the Pixy Cam’s panning servo motor in the direction of the object. This will increase the view of the Pixy Camera and precision of the robot’s ability to follow a color. Because SPI communication is full duplex, the HS12 can send data to the Pixy Cam’s 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 Cam’s 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. DifficultiesOriginally, 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 robot’s 12 volt power supply fixed the problem of the moving servo motors.

4. LimitationsWith 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 robot’s responses would lag because of too much time going into retrieving data from the Pixy Camera.

5. CapabilitiesThe Pixy Camera’s 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

6


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

7


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

8

Figure 6: Xbee TransmitterFigure 5: Xbee Receiver


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.

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 camera’s main power supply.

XBEE Modules:

There are two XBEE modules: XBEE router (connects to the computer) and XBEE coordinator (connects to the HS12).

9


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.

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

10


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 in a graduate year of college occupies much of one’s time. Overall, the assistance of a TA for questioning throughout the day would have made this project’s 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

intro to microcontrollers - final project design report

Documents

sensors sonars

array of data

sonars pioneer

color codes

moving color

stationary color

color signature

selected color