ECE 477
Digital Systems Senior Design Project
Rev 9/12
Homework 9: Software Design Considerations
Team Code Name: Wall-E Prototype I
Group No. 01
Team Member Completing This Homework: Hang Xie
E-mail Address of Team Member: xie20 @ purdue.edu
NOTE: This is the last in a series of four “design component” homework assignments, each of
which is to be completed by one team member. The body of the report should be 3-5 pages,
not including this cover sheet, references, attachments or appendices.
Evaluation:
SEC
DESCRIPTION
MAX
1.0
Introduction
5
2.0
Software Design Considerations
30
3.0
Software Design Narrative
30
4.0
Summary
5
5.0
List of References
10
App A
Flowchart/Pseudo-code for Main Program
10
App B
Hierarchical Block Diagram of Code Organization
10
TOTAL
100
Comments:
Comments from the grader will be inserted here.
SCORE
ECE 477
Digital Systems Senior Design Project
Rev 9/12
1.0 Introduction
This report summarizes the software development of the project Wall-E Prototype. In this
introduction section, an overview of the project, with a focus on software design considerations
is presented. Following the introduction, section 2.0 discusses software design considerations in
more depth. This section has a heavy focus on the software development on the microcontroller.
The information about memory mapping, port pin mapping, as well as the peripheral utilization
are the major focuses of the discussion. In section 3.0, the software development of the project is
presented in a higher level abstraction. In this section, the software design narrative of the whole
project is described in detail. After a brief summary of the report in section 4.0, reference is
listed in section 5.0, and relative block diagrams, as well as other illustrations are included in the
appendixes.
As a mobile robot with object recognition and obstacle avoidance capability, the Wall-E
Prototype I requires both mobility and intelligence (computation power). A single
microcontroller is not powerful enough to perform all the functions required, so the tasks are
split into different parts and realized on different hardware platforms. The microcontroller is
responsible for direct robot control and obstacle avoidance, while the server hardware (a
Raspberry Pi, or an Atom board) performs the more “heavy duty” object recognition tasks.
Because of this multi-platform setup, different programming languages and development
environments are used. A simple example is that while on the PIC24 microcontroller C language
and C30 compiler are used, SimpleCV and Python are the major development tools on the
Raspberry Pi. These details are discussed in more details in the following sections.
2.0 Software Design Considerations
As described in the introduction section, the Wall-E Prototype I project includes multiple
hardware platforms. (At the present, the team is simultaneously working on two different object
recognition solutions, one being the Raspberry Pi, the other being the Atom board. However, in
this report, the major discussion focuses on the Raspberry Pi solution due to the more advanced
development status on the platform comparing to the Atom board).
For microcontroller software development, timing is a critical factor due to the real time
operation nature of its task. With a full real time interrupt architecture is difficult to implement,
the team uses a polling loop configuration to create a non-continues movement solution. The
-1-
ECE 477
Digital Systems Senior Design Project
Rev 9/12
main loop can be described in three different stages: Sampling, Checking, and Action. During
each iteration of the main polling loop, different peripherals samples data and raise flags
accordingly. Then in the main program, different flags or variables are checked, and based on the
flags, a service subroutine is entered to perform an action. At the end of the action, the robot is
halted, and the loop starts again (The detailed logic flow is included in Appendix A for
reference).
The server (Raspberry Pi or Atom board), in the other hand, is a different matter. Because
of the existence of an operating system, the object recognition software can not be served in real
time. Also, to maximize the utilization of the microcontroller, most functions are not performed
on the server. The server serves solely as a “reference” for the microcontroller for the relative
position between the robot and the ball. Because of the reasons described above, the program
running on the server is an infinite loop that keeps looking for the target object (the ball) and
outputs the relative position to the microcontroller (whether the robot should turn left, right, go
forward, or go backward).
Now go into more details about the microcontroller software design. The
PIC24FJ256GA106 microcontroller on the robot is programmed in C and compiled with
Microchip’s MPLAB C30 compiler. All the variables and program are located in the 256K flash
memory.Four peripherals of the micro controller are used to achieve the desired functions: PWM,
UART, I2C and ATD. These peripherals are utilized for the following functions respectively:
Motor and servo control; communication with the server; communication with the compass;
collecting ultrasonic sensor data.
Mapping of the external port interfaces of the peripherals are listed below:
PWMs: PWM1: RP6 (Remappable port pin 6), PWM2: RP7, PWM3: RB12, PWM4: RB13,
PWM5: RP14, PWM6: RP29; UARTs: UART1_RX: RP11, UART1_TX:RP12, UART2_RX:
RP16, UART2_TX: RP30; I2Cs: I2C_SDA: RP10, I2C_SCL: RP17; ATDs: ATD1: AN1, ATD2:
AN8, ATD3: AN9, ATD: AN11;
Then the configuration registers for the different peripherals are as following:
Configuration registers for PWM are: OCxCON1; OCxCON2; OCxR; OCxRS.
Configuration register for UART are: U1BRG; U1TXIPx; U1STA; MODE (which is set to 8 bit,
no parity, 1 stop bit, 9600 baud rate); For debugging and testing, an extra set of UART is utilized
-2-
ECE 477
Digital Systems Senior Design Project
Rev 9/12
to connect to the MAX3232 chip, which can be directly hooked up to any computer to display
the data.
3.0 Software Design Narrative
The top level main program is a polling loop which runs on the microcontroller that
checks different flag iteratively. Different flags are raised by different peripherals, which receive
signals that come from different hardware of the robot (server included). The microcontroller
executes different service subroutine based on the flags in the end of the loop. In other words,
during each iteration of the main loop, microcontroller first checks all the flags for the current
status of the system, then in the end of the loop, based on the flags, microcontroller determines
the action should be taken at the moment. After the action is taken, the robot is stopped, and the
loop is executed again. Until a new action command is executed, the robot stays still to cancel
the effect of any signal lagging. (Basically, the robot moves for a short period time and a short
distance, then it stops to check the new surrounding status, then moves again based on the new
status) (This hierarchical arrangement is illustrated as an diagram included in Appendix B)
The peripherals that rise flags are ATD, I2C, and UART. The four sets of ATD receive
data from the ultrasonic sensors that are located around the robot, and provide the basic
surrounding clearance status of the robot to the microcontroller. I2C receives signal from the
digital compass which gives feedback to the microcontroller about the heading of the robot. As
of UART, it is used to communicate with the server (Raspberry Pi or Atom board), which gives
the relative location of the ball (if there is any) to the robot (6 different characters are used to
represent the different relative locations of the ball to the robot: Front, Back, Mid, Left, Right,
None, which tells the robot which way should go). On the other hand, the program on the server
uses image processing libraries (SimpleCV for Raspberry Pi, OpenCV for Atom board) to obtain
the vector distance from the object to the center of the video frame (where the tip of the robot
arm is at), and different signals are sent via UART to the microcontroller to set the 6 different
flags for microcontroller to referent.
For illustration purpose, here is an example of the program flow in a hypothetical
situation. Upon power up, the microcontroller immediately sets up the on-chip peripheral
registers, and start clocking at 4MHz. If the proximity threshold flag is triggered by the ATD for
the front ultrasonic sensor, but the server communication has only the “None” flag high. This
-3-
ECE 477
Digital Systems Senior Design Project
Rev 9/12
indicates the front object is not a ball, but an obstacle. A series of on-chip commands will be
executed, and with the help of sensor feedback, the robot is able to move around the obstacle in
front of it. Then as the front is clear, and no ball is detected, the robot slowly turns around until it
goes through all 360 degrees. During the turning event, if a ball is detected, the robot starts to
move towards the ball based on the command received from the server. If no ball is detected
during the turning event, moves forward at the starting direction for a short period of time, then
repeat the turning process until a ball or an obstacle is detected.
The following are the functional modules inside the main loop of the code and their
development status:
1. Microcontroller side software:
Pre-execution stage:
Init: initlization of the peripherals and other settings. (Finished PWM, and UART
receving)
Sampling stage:
ATDSample: sample ATD channels. (Under development)
UARTSample: sample UART receiving port. (Under development)
I2CSample: sample I2C data. (Under development)
Checking stage:
CheckAll: check all flags. (Finished, simple if statements in main loop)
Action stage:
Act: activate different PWM channels based on the flag status. (Finished, several
different subroutines to accommodate different flag situations)
2. Server End software:
Ball recognition: recognize ball and obtain its vector distance from the center of frame. (Finished
on Raspberry Pi, under development for Atom board)
Signal transmitting: based on the ball position transmit an appropriate message through UART.
(Under development on both platforms)
4.0 Summary
This report serves as a summary to the software narrative of the Wall-E Prototype I project.
In section 1.0, an introduction is given for a quick overview of the project. Follows section 1.0,
-4-
ECE 477
Digital Systems Senior Design Project
Rev 9/12
the software design considerations are discussed to reveal the thought process behind the
software development of the project. Before this summary section, the higher level software
narrative is presented in section 3.0, along with the current development status of each software
module.
-5-
ECE 477
Digital Systems Senior Design Project
Rev 9/12
5.0 List of References
[1] Microchip, (2010). PIC24FJ256GA110 Family Data Sheet. [Online]. Available:
http://ww1.microchip.com/downloads/en/DeviceDoc/39905e.pdf
[2] SimpleCV, (2012). SimpleCV’s Online Documentaion. [Online]. Available:
http://simplecv.org/docs/
[3] Python community, (2013). Python Documentation. [Online]. Available:
http://www.python.org/doc/
[4] Raspberry Pi Foundation, (2013). Raspberry Pi. [Online]. Available:
http://www.raspberrypi.org/
[5] Xamox, Object Tracking with SimpleCV. [Online]. Available:
https://gist.github.com/xamox/2438871
[6] Matt Richardson and Shawn Wallace, (2012). Getting Started with Raspberry Pi. [Book]
-6-
ECE 477
Digital Systems Senior Design Project
Appendix A: Flowchart/Pseudo-code for Main Program
-7-
Rev 9/12
ECE 477
Digital Systems Senior Design Project
Appendix B: Hierarchical arrangement of the software modules
-8-
Rev 9/12