ECE 477
Digital Systems Senior Design Project
Spring 2008
Homework 9: Software Design Considerations
Due: Friday, March 21, at NOON
Team Code Name: Team KANG / Sentinel Mark I
Group No. 1
Team Member Completing This Homework: Ilya Veygman
E-mail Address of Team Member: iveygman @ 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 completed homework will count for 20%
of the individual component of the team member’s grade. The body of the report should be 35 pages, not including this cover sheet, references, attachments or appendices.
Evaluation:
SCORE
DESCRIPTION
Excellent – among the best papers submitted for this assignment. Very few
corrections needed for version submitted in Final Report.
Very good – all requirements aptly met. Minor additions/corrections needed for
9
version submitted in Final Report.
Good – all requirements considered and addressed. Several noteworthy
8
additions/corrections needed for version submitted in Final Report.
Average – all requirements basically met, but some revisions in content should
7
be made for the version submitted in the Final Report.
Marginal – all requirements met at a nominal level. Significant revisions in
6
content should be made for the version submitted in the Final Report.
Below the passing threshold – major revisions required to meet report
*
requirements at a nominal level. Revise and resubmit.
* Resubmissions are due within one week of the date of return, and will be awarded a score of
“6” provided all report requirements have been met at a nominal level.
10
Comments:
Comments from the grader will be inserted here.
ECE 477
Digital Systems Senior Design Project
Spring 2008
1.0 Introduction
The Sentinel Mark I is a sentry turret capable of moving a pan/tilt assembly to sense,
target and fire upon targets using ancillary sensors and a video processing algorithm to determine
the location of targets. The main software considerations include the video processing
algorithm, motor control, ancillary sensors and the user override interface.
2.0 Software Design Considerations
The software is to be written on the Freescale MC9S12XDP512 microcontroller.
According to its datasheet, there is a total 32K RAM, 512K Flash and 4K EEPROM available.
There is paging available for the Flash (4 pages of 128K), which will be used, if necessary, by
this project. The code will be primarily stored in Flash, which exists in the local memory
between the addresses $4000 and $FFFF, with the reset vectors occurring from $FF10 to $FFFF
[1]. The Flash between $4000 and $8000 and between $C000 and $FFFF is unpaged, while the
memory in between those two regions is paged. Code will be stored starting at $8000. The stack
pointer will be initialized to $3FFF and will grow down from there. This should leave a great
deal of room for global variables to be stored between $4000 and $8000. Most of this memory
will likely go unused. The interface registers are mapped from address $0000 to $0367 [1].
There are several peripherals utilized in this program. First, the enhanced capture timer
peripheral will be used to send control signals to the stepper motors. The control signals will be
sent through six pins on Port AD initialized as general purpose outputs via the port integration
module (PIM). The timer output compare register, TIOS, must be initialized to have at least one
channel acting as output compare by setting the corresponding channel’s bit high. The
corresponding bits of TIE will need to be set high as well. The timer system control registers,
TSCR1 and TSCR2, will be initialized 0x80 and 0x87, respectively. This will enable the timer,
and allow overflow interrupts and set the prescaler to 128, respectively. Due to a fast bus clock,
a large prescaler is desired to have a reasonable stepper clocking speed. The values of TC7-0,
corresponding to enabled timer channels, will be set as high as possible for the same reason as
the prescaler setting [1]. The speed of the motors will be controlled by a global delay variable.
The SCI interface will have only one channel activated to accommodate the user override
interface. The baud rate registers, SCIBDH and SCIBDL will be set according to the fastest
possible speed allowed by the terminal on the computer’s end. SCICR2 will be set to 0x2C to
enable both transmitter and receiver as well as allow interrupts [1]. The purpose of bidirectional
-1-
ECE 477
Digital Systems Senior Design Project
Spring 2008
transmitting is to allow some form of software debugging on the board in terms of sending
control and status messages to the user interface upon startup or various errors.
The IIC interface will be initialized in master transmit mode by setting the control
register, IBCR, to 0xB0. The RTI peripheral, which is to be used in reading inputs from the
motion sensors and IR receivers, will be initialized like it was for the 9S12C32 module in
ECE362. CRGINT will be set to 0x80 and CLKSEL will be set to make the RTI derive its clock
from the bus clock. RTICTL will be initialized to 0xFF to allow interrupts approximately every
25 times per second. The XEBI (external bus) interface will be used to interface to the external
SRAM on the board via ports A, B, D and parts of K as well as PE2 (the R/W signal). EBICTL0
will be initialized to 0x16 to give 20 bits of addressing and normal threshold levels [1].
The code will be organized as a hybrid model, with both round-robin polling of
peripherals and interrupts being utilized. The reason for this is that while most of the operations
may be done by polling, some things such as override commands from the friendly detection and
user interface will need to be able to stop the device from targeting and/or firing upon command.
Peripherals such as motion sensors may be polled because the micro will be running fast enough
to catch a change of state before it goes away.
3.0 Software Design Narrative
The code will be organized into four main blocks: video processing, motor control,
ancillary sensing and user override interface. The video processing will only be called upon a
trigger from the ancillary sensors and will be responsible for capturing a target image and
determining the target coordinates. The motor control block will be responsible for moving the
pan/tilt assembly and camera platform in either automatic or manual override control modes as
well as translating target coordinates to a physical position. Ancillary sensing will encompass
the motion sensors and friendly detector and will be responsible for notifying the machine that a
given sensor was tripped. The user override interface will be responsible for toggling between
the manual and automatic modes as well as full control over the machine during manual mode
operation.
The main program will first initialize the PLL and initialize all peripherals. After this, it
will set the camera via I2C. It will then enter an infinite loop containing two sub-loops: one for
manual mode and one for automatic mode. The default operating mode will be manual,
whereupon the user will have to define a “zero” or home position as a reference for the position
-2-
ECE 477
Digital Systems Senior Design Project
Spring 2008
tracking of the stepper motors. This ought to be done manually so that the machine knows which
way is “forward”. An interrupt from the SCI containing a toggle command between manual and
automatic modes will switch this. Upon switching from manual to automatic mode, a routine
will be run to capture background images and set the device pointing to its “zero” position.
In automatic mode, the code will poll the motion sensors for a change from high to low
and enter the automatic targeting routine. If targeting is enabled, the motor control code will
move the camera to the region where the motion sensor was tripped. After this, the video
processing software will capture an image of the target area and then run a subtract and threshold
algorithm to determine where a target exists. Another algorithm will run to determine the center
of the region where greatest difference exists, and these coordinates will be sent to the pan/tilt
assembly motors, which will position the gun to target, and subsequently fire the weapon, if
firing is still enabled. At certain points in this loop, the code may get commands via interrupt to
stop what it is doing and enter manual mode. Specifically, those points are between ancillary
detect notification and running the video algorithm, and right before the weapon is fired.
Depending on how fast it takes to run the video algorithm, it may be possible to add one more
such point when the target coordinates are sent to the motors to reposition the pan/tilt assembly.
In manual mode, the loop will wait for commands received from the user interface and
then execute actions based upon predetermine codes sent to the device. The ancillary sensors
and image capture/video processing will not be active during this mode and the motors will rely
solely on commands from the user to move. A separate, analog video feed independent of the
video processing algorithm will run to the user interface to allow the user to view what the
camera sees at any time. Only a certain “revert to automatic mode” code will cause the program
to break out of this sub-loop and (presumably) enter the other. The pseudo-code for both main
sub-loops has been developed, but the actual code will not be ready until the four major blocks
have been completed.
Video processing, once again, will only run when the device is in automatic mode and an
ancillary detect signal has been sent. Upon entering the routine, the software will wait until it
has received an image captured by the camera, which it will store in either paged memory or the
external RAM (depending on which one is easier and faster). Once this has completed, the
software will run a pixel-by-pixel subtract and threshold algorithm based on various algorithms
found online. These will have to be adjusted to available hardware availability. The listed
-3-
ECE 477
Digital Systems Senior Design Project
Spring 2008
algorithm also has the ability to determine the location of the target [2]. This code is still in the
pre-development stage; however testing protocols have been developed.
Motor control will operate in one of two ways, depending on if the main program is
running in manual or automatic mode. If it is in manual mode, then the software will wait until it
receives a command relating to moving one or more of the motors. When this happens, it will
call the correct motor control routine. This routine will get the current position of the motor to
be moved, check to see if it is at a preset limit, then either move to the new position and store it
or do nothing. The position of the motors, in general, will be tracked based on an initial “zero”
or “home” position defined at startup. The current position will be tracked by incrementing or
decrementing a counter for each motor, once for each step of the stepper. For example, every
step panning left adds one to the pan counter and vice-versa for right. One important thing to
note is that when panning in manual mode, both the assembly and camera platforms will be
moved left or right concurrently to allow the user to keep the targeting reticule lined up with the
camera’s viewing angle. This will not necessarily happen in automatic mode. The speed of
stepping in manual mode will also be slower than that in automatic mode. This is because
manual mode will not use a so-called SLERP approach to prevent instability due to inertia.
In automatic mode, the motor control will work in parallel to the video algorithm. After
an ancillary sense signal, a routine will move the camera platform to look at the corresponding
region where motion was sensed, if targeting is enabled. It will then wait for coordinates from
the video algorithm, which it will translate into a number of steps up/down or left/right for the
main assembly. This will be accomplished by a lookup table, which will have to be manually
calibrated during development. There will be only one lookup table for all regions, which is
accomplished with a constant offset being used for every separate region for horizontal steps.
In both cases, the speed of the motors will be controlled by a stepping clock generated by
the timer module. The speed of stepping can be simply varied by changing how often these
interrupts occur by incrementing or decrementing certain global variable delay counters. A
SLERP algorithm will additionally be used with the automatic control mode to maximize speed
and minimize wobble. SLERP is basically an interpolation algorithm that can be adapted for
slow speed at the ends of motion and fast speed in the middle of the path [3].
The ancillary sensing block will occur almost entirely within the RTI interrupt and main
polling block. Much like the pushbutton debouncing done in ECE362 labs, the RTI will look for
-4-
ECE 477
Digital Systems Senior Design Project
Spring 2008
a change of state corresponding to going from high to low for the motion sensors and going from
high to low and the friendly detection sensors staying low for a certain amount of time. The
purpose of this, especially for the friendly detection sensors, which are infrared receivers, is to
reduce some of the noise due to ambient sources of light radiation. The RTI interrupt will set
flags, which will be polled by the main program.
The user override interface encompasses several files already mentioned, and will exist
partially in main and a separate file which exists for the purpose of keeping main from getting
very long. Further elaborating upon the functionality of main, this block will be activated when
an override command is received through SCI. From there, it will wait for commands from the
user to do various actions. For example, the command may be “move left” which will cause the
pan/tilt assembly and camera platform to move to the left concurrently per the method described
in the motor control block. The commands will be one-character signals which will then be run
through a switch statement to find the proper action.
All ISR code may be found in interrupt.c. There are three service routines for the RTI,
SCI and timer modules as well as initialization functions for all utilized parameters within this
file.
4.0 Summary
The code is organized into four main blocks to be stored in Flash: video processing,
motor control, ancillary sensing and user override interface. Various shareware-type algorithms
such as the video detection and threshold algorithm and the SLERP approach will be utilized by
porting them to this project’s hardware limitations. The code will be written entirely in C using
CodeWarrior and main will be organized according to a hybrid coding structure.
-5-
ECE 477
Digital Systems Senior Design Project
Spring 2008
List of References
[1] Freescale MC9S12XDP512 Microcontroller datasheet, available HTTP:
<http://cobweb.ecn.purdue.edu/~477grp1/datasheets/MC9S12XDP512V2.pdf>
[2] Wauthier, Fabian. “Motion Tracking.” School of Informatics, University of Edinburgh
fourth year honors project, available HTTP:
<http://www.anc.ed.ac.uk/demos/tracker/>
[3] Blow, Jonathan. “Understanding SLERP, Then Not Using It.” The Inner Product. 26
February 2004. Available HTTP:
<http://number-none.com/product/Understanding%20Slerp,%20Then%20Not%20Using%20It/>
-6-
ECE 477
Digital Systems Senior Design Project
Spring 2008
Appendix A: Flowchart/Pseudo-code for Main Program
Start
Init. peripherals
mode = manual
Camera settings
through I2C
Manually set zero
position for motors
auto
manual
No
Get
bckgnd
images
Control
mode?
Got SCI
data?
Motion
sensed?
Yes
Mode = manual
Lookup action
Was
“mode=
auto?”
No
Yes
Targeting
on?
Yes
Yes
Move camera
No
Video algorithm
Execute action
No
Targeting
on?
Yes
Fire weapon
No
Fire
disabled?
Yes
-7-
Move assembly
No
ECE 477
Digital Systems Senior Design Project
Spring 2008
Appendix B: Hierarchical Block Diagram of Code Organization
main()
mode = auto
mode = manual
GetCommand()
Fire()
Execute()
PositionCamera()
MoveHoriz()
MotionDetected()
MoveVert()
FriendDetected()
override()
Fire()
SetZeroPos()
VideoAlg()
SwitchToAuto()
ReadCamera()
WriteRAM()
ReadRAM()
AutoMotor()
GetCoords()
Lookup()
SLERP()
-8-
ECE 477
Digital Systems Senior Design Project
Spring 2008
Appendix B: Hierarchical Block Diagram of Code Organization
ISRs
tim_isr()
rti_isr()
sci_isr()
RTI_Init()
SCI_Init()
-9-
TIM_Init()