Project Report

advertisement
EE4214 Group X Project Report:
Title
Finger-Finger Revolution
Contents
1. Objective
2. Project Area
3. Hardware
4. System Overview
5. Flow Chart
6. Stress Test
7. Group Members
8. Gantt Chart
9. Task Criticality
10. Activation Modes
11. Constraints
12. Periodic Task Scheduling Analysis
13. Timing Diagram
14. State Transition Diagram
15. Context Diagrams (Level 0, 1, 2)
Objective
The objective of the project is to realize an interactive rhythm-and-hand gesture game
platform using real-time embedded operating system and some electronic hardware
components. The Player will perform hand gestures through an array of IR sensors according
to visual and musical cues produced by the system.
The Player starts the game by swiping his fingers over the IR inputs. When the game starts,
background music is played and scrolling symbols will then be shown on the LCD. The Player
responds to the corresponding symbols by swiping his hand through a series of IR sensor
(labelled accordingly with various symbols). A game lasts for 15 seconds, at the end of the
game the number of correct hits will be displayed
Project Area
The uCsimm board will provide the following real-time functions for the interactive rhythmand-hand gesture game their priorities are listed starting from highest priority.
1) Gesture Detection:
The IR sensors are polled for inputs at periodic intervals.
2) Musical Tones:
A background music consisting of tones will be played throughout the game play of
15 seconds.
3) Visual Display:
The LCD is updated periodically to reflect the symbols scrolling across. The character
is dropped from the screen when the input corresponding to the character is
correctly input or when the character reaches the other end of the screen and is not
activated.
4) Scoring System:
A counter is updated whenever the player activates the correct input sensors.
5) Game Timer:
The game timer is based on the real time clock which will keep track of 15 seconds of
game play. The game play will automatically halt once 15 seconds is up.
Hardware
LED / Display
Sound Buzzer
uCSimm
Array of IR
Sensors
Ethernet Bus
Centralized
Database
LED/Actuators:
Actuators such as LCD and LED is used to output information to the Player of Finger-Finger
Revolution like selecting difficulty level to play, view high score. During the game, a list of
scrolling characters (1 to 4) will appear on the LCD.
Sound Buzzer:
Piezo buzzer is used to play background music.
Array of IR Sensors:
The array of IR sensors is used to gather input from the Player for various functions like
selecting of difficulty levels and also during in game as a Player swipes his hand through the
IR sensors to register a move.
Hardware Specifications
1) Voltage Regulator
Schematic diagram
Actual circuit
To power up the circuitries used in our project, we made use of the IC 7805 to regulate an input
voltage of 7.5v to 5v. The output voltage of the regulator is consistent and has an output current
limit of 1A, which is sufficient for our usage. The addition of two capacitors serves to remove any
noise present in the power source.
2) IR Circuit
Schematic Diagram
Actual Circuit
The IR circuit consists of two parts, the Transmitter and the Receiver. The Transmitter circuit is
straight forward, consisting of an IR transmitter and a current limiting 100 Ohm resistor. For the
Receiver, since the IR Receiver output is analogue and for our usage we need a digital input, we
designed an Analogue to Digital circuit to convert the signal to digital. A NPN transistor is used to
realize this by being in a switch configuration. When the IR receiver isn’t receiving any IR light, it will
‘turn off’ the NPN transistor, thus creating a ‘high’ 5v signal at the output to the digital input port.
On the contrary, when the IR receiver receives sufficient IR light, it will ‘turn on’ the NPN transistor,
thus creating a ‘low’ 0v signal at the output to the digital input port. To sum it up, the logic table at
the output of the IR circuit is as such:
Finger Detection
Logic level at output
Detected (no IR light received)
5v or ‘High’
Not Detected (IR light received)
0v or ‘Low’
3) Buzzer High Pass Filter
Schematic Diagram
Actual Circuit
When we first made use of the PWM0 port pin to output a tone to the buzzer, we realized that
there’s a consistent humming sound even though the PWM0 is at logic 0. After checking the pin with
a voltmeter, we discovered that there is a constant 0.3v output despite it being at logic 0. Since the
buzzer we used is digital by nature, the constant 0.3v must have been the culprit in causing the
humming sound. To solve the problem we made use of a High Pass Filter circuit to remove the 0.3v
constant (DC) voltage at the PWM0 output. The formula to calculate the cutoff frequency of the
filter is as such:
With the 100nF capacitor and 100k Ohm resistor, the high pass filter’s cutoff frequency is 15.9 Hz.
This means that it will not filter away any audible output since the human audible range is between
20Hz to 20KHz.
4) LCD Connection
Schematic Diagram
The LCD module is connected to the controller’s I/O ports as shown above. Since we are using the 4
bit data mode, LCD pins DB0 to DB3 will not be connected.
System Overview
Flow Chart
Stress Test
Ensures Finger-Finger Revolution has it background music play without pauses or skipped
notes while the uCsimm board gathers input from the 4 pairs of IR sensors and keeping the
LCD updated with characters (arrow directions) as per the difficulty mode selected. Beeps
corresponding to correct or wrong moves made by user will have to be played within a
certain time period after the Player input has been performed.
Group Members
Matric No.
Name
Email
U075601H
U075595W
U075603E
U075593X
U075589W
U075608M
ANG JIT HWEE
CHOO JIA WEI
GAVIN TEO TECK WEE
NAH GUO YUAN
NG WEE LIAT
ONG JUNJIE
u0705601@nus.edu.sg
u0705595@nus.edu.sg
u0705603@nus.edu.sg
u0705593@nus.edu.sg
u0705589@nus.edu.sg
u0705608@nus.edu.sg
Gantt chart
Aug 2009
ID
Task Name
Start
Finish
Sep 2009
Oct 2009
Nov 2009
Duration
16/8 23/8
1
Brain Storm /Finalize Project Proposal
17/8/2009
4/9/2009
3w
2
Read up relevant sections of the RTAI
Manual
17/8/2009
11/9/2009
4w
3
Playing of Music
4/9/2009
18/9/2009
2.2w
4
LCD Display
4/9/2009
18/9/2009
2.2w
5
IR sensors detection
4/9/2009
18/9/2009
2.2w
6
System Integration
21/9/2009
5/10/2009
2.2w
7
Intensive Testing and fine tunning
5/10/2009
16/10/2009
2w
8
Documenting/Preparation for
Demostation
19/10/2009
30/10/2009
2w
30/8
6/9
13/9
20/9
27/9
4/10 11/10 18/10 25/10 1/11 8/11
Task Criticality
Firm RT Tasks:
1. UpdateMove task
A delay in updating the LCD with the visual cues required to notify the User to activate
the correct IR inputs will affect game-play negatively.
2. PWM task
A delay in playing of a musical note or skipping the note altogether will be noticeable by
the user and impact the game-play experience negatively.
3. LCD task
LCD task is responsible for low-level I/O for the on-screen display of all visual elements
of the game platform. Any missing characters on-screen due to the task being skipped or
delayed can impact the game play experience negatively.
4. IR task
As the user will take a finite amount of time to respond to the visual cues by swiping
his/her hand at the IR sensors, an occasional miss of a deadline to poll the IR sensors is
acceptable.
Soft RT Tasks:
1. UpdateScore task
The task of incrementing the score after a user correctly activated the IR input according
to the visual cue can have its deadline missed occasionally, as long as the task completes
before the game ends, when 15 seconds has elapsed before the correct score is
displayed.
2. UpdateTime task
A typical game lasts 15 seconds, and this is kept track of using RTAI internal timers in the
background. The UpdateTime task displays the value of the internal timer at the LCD. An
occasional delay or skip in the update of the on-screen timer is acceptable as long as the
internal timer keeps good time and the game is stopped once 15 seconds has elapsed.
Activation Modes
Time Driven (Periodic) Tasks:
1. UpdateTime task
The game time counter depends on the periodic nanosecond-resolution tick of the RTAI
internal timer for accurate time keeping and is updated once every second. This
information is then reflected on the LCD in the form of a countdown sequence.
2. PWM task
The music playback is dependent on periodic delays between each note to achieve the
desired tempo. This tempo changes with the difficulty level of the game.
3. LCD task
The LCD is updated with the number of seconds elapsed since the game is started, and
the visual cues indicating to the user which IR input to be activated scrolls from left to
right at fixed periods according to the difficulty of the game selected.
4. IR task
The system polls the IR sensors at regular intervals to check for user input and sense
input information to the CalScore task for evaluation and score computation.
Constraints
Timing Constraints:
Activation:
1. UpdateTime task
The game timer makes use of the RTAI internal timer with a nanosecond-resolution
tick to increment a counter that counts up to give a 1 s period. The UpdateTime task
runs at 1000 ms intervals and completes within 20 ms.
2. PWM task
A musical note is played at 500 ms intervals and the playback of a note completes
within 20 ms.
3. LCD task
The LCD task provides the I/O service for updating of the time elapsed and next
visual cue at 250 ms intervals. The LCD task output each character within 10 ms.
4. IR task
As the User will take a finite amount of time to respond to the visual cue and thus
activate the corresponding IR sensor, the IR inputs are polled at 250 ms intervals.
The readings of all 4 IR sensors are completed within 10 ms.
5. UpdateMove task
The UpdateMove task scrolls the visual cues at 250 ms intervals and completes
within 20 ms.
6. CalScore task
The CalScore task takes in user input values read by IR task and evaluates the input,
incrementing a score counter if the input matches that as indicated on the LCD at
250 ms. The task completes within 20 ms.
Precedence (In order):
1. IR task
2. CalScore task
The IR task will have to first obtain user inputs by polling the IR sensors and converting
the inputs to binary sequences for evaluation by the CalScore task. If the input matches
the visual cue on the LCD, a score counter is incremented by the CalScore task.
Resource Constraints and Inter-Process Communication:
1. Mailbox Message Passing
The visual cue instructions are sent from the UpdateMove task to the LCD task via a
mailbox, which is also shared with the IR task. The IR task passes user input information
to the CalScore task for evaluation and score computation. Binary semaphores are used
to ensure mutual exclusion when writing to the mailbox.
2. Controller-to-PWM FIFO
The Controller reads a pre-defined sequence of musical notes and sends it to the PWM
for playback via the dedicated Controller-to-PWM FIFO. Binary semaphores are used to
ensure mutual exclusive access to this resource shared between the Controller and the
PWM task.
Periodic Task Scheduling Analysis
The application consists of a fixed set of periodic tasks with known periods, and these tasks are
completely independent of each other. All tasks have deadlines equal to their period, and their
fixed worst-case execution time (wcet) is known beforehand. All of the system’s overheads,
including context switching time, are ignored during the analysis.
Task
Frequency (f)
Period (Ti)
Computational
Time (Ci)
Priority
(P)*
Utilization
(Ui)
PWM
8 Hz
500 ms
20 ms
6
0.04
LCD
4 Hz
250 ms
10 ms
1
0.04
IR
4 Hz
250 ms
10 ms
2
0.04
CalScore
4 Hz
250 ms
20 ms
3
0.08
UpdateMove
4 Hz
250 ms
20 ms
4
0.08
UpdateTime
1 Hz
1000 ms
20 ms
5
0.02
*Lower integer values for higher priorities, according to RTAI programming convention
Greatest Common Divisor (Minor Cycle) = 250 ms
Lowest Common Multiple (Major Cycle) = 1000 ms
Obtaining the Processor Utilization Factor:
𝐢𝑖
UP = ∑𝑛𝑖= 1 𝑇𝑖 = 0.300
Up ≤ 1
Hence, schedulability depends on the scheduling algorithm. Computing the Utilization Least
Upper Bound (1973, Liu and Layland):
UlubRM = n(21/n - 1) = 0.735
In another case, for large n, n → ∞:
Ulub → ln 2 ≈ 0.693
Since Up ≤Ulub in both cases, the task set is schedulable with RMA.
Additionally, computing the Hyperbolic Bound (2000, Bini et al.):
𝑛
∏(π‘ˆπ‘– + 1) = 1.34 ≤ 2
𝑖=1
Thus the set of 6 periodic tasks is schedulable with RMA.
As an additional note, the context switching time as reported by the uCsimm at boot is rated at
26158 ns.
Timing Diagram
State Transition Diagram
Context Diagrams
Level 0:
Level 1:
Level 2, Part 1:
Level 2, Part 2:
Conclusion
This project has allowed the team to learn and experience Real-Time designing and
programming, such as
• Designing timing diagram and data flow diagrams,
• Scheduling tasks,
• Assigning priorities,
• Implementing inter-process communications by means of RTAI.
There are improvements to be made if more time is given, such as implementing multi-player
mode through an inter-networking process.
Download