Final Design Report - Senior Design - Iowa State University

brickcompetitiveΛογισμικό & κατασκευή λογ/κού

14 Δεκ 2013 (πριν από 3 χρόνια και 4 μέρες)

101 εμφανίσεις

1

Dec


1002

Project Plan


Design Through the Curriculum on
Embedded Systems


Dec10
-
02


Final Report





Client:

Computer Engineering Department


Advisors:

Dr. Akhilesh Tyagi & Jason Boyd


Members:

Aisha Grieme

Jeff
rey

Melvin

Dane Seaberg


Date:

December 6
,

2010


2

Dec


1002

Project Plan


Contents

Contents

................................
................................
................................
................................
.......

2

List of Figures

................................
................................
................................
...............................

3

List of Tables

................................
................................
................................
................................

3

List of Definitions

................................
................................
................................
.........................

4

Executive Summary
................................
................................
................................
......................

4

Acknowledgem
ents

................................
................................
................................
.....................

5

1.

Problem Statement

................................
................................
................................
..........

5

2.

Solution Approach

................................
................................
................................
............

6

2.1.

Concept Diagram

................................
................................
................................
......

9

3.

Operating Environment

................................
................................
................................
..

10

4.

Intended Use and Users

................................
................................
................................
.

10

5.

Assumptions and Limitations

................................
................................
.........................

10

5.1.

Assumptions

................................
................................
................................
............

10

5.2.

Limitations
................................
................................
................................
...............

10

6.

End Product and Deliverables

................................
................................
........................

10

6.1.

Robot

................................
................................
................................
.......................

10

6.2.

Project Tas
ks

................................
................................
................................
...........

11

6.3.

Student Documentation

................................
................................
.........................

11

6.4.

TA Documentation

................................
................................
................................
..

11

6.5.

Demonstration

................................
................................
................................
........

12

7.

Approach Used

................................
................................
................................
...............

12

7.1.

Design Objectives

................................
................................
................................
....

12

7.2.

F
unctional Requirements

................................
................................
........................

12

7.3.

Design Constraints

................................
................................
................................
..

12

7.4.

Technical Approach Considerations and Results

................................
....................

12

7.5.

Testing Approach
Considerations

................................
................................
...........

16

7.6.

Recommendations for Project Continuation or Modification

................................

17

8.

Detailed Design

................................
................................
................................
..............

17

8.1.

Course Design

................................
................................
................................
.........

17

8.2.

Hardware and Software

................................
................................
..........................

19

3

Dec


1002

Project Plan


8.3.

Testing

................................
................................
................................
.....................

19

8.4.

Documentation

................................
................................
................................
.......

20

9.

Resource Requirement

................................
................................
................................
...

21

9.1.

Team Effort Requirements

................................
................................
......................

21

9.2.

Required Resources

................................
................................
................................

21

9.3.

Financial Requirements

................................
................................
..........................

21

10.

Schedule

................................
................................
................................
.........................

22

11.

Project Team Information

................................
................................
..............................

22

11.1.

Client

................................
................................
................................
.......................

22

11.2.

Advisors

................................
................................
................................
...................

22

11.3.

Members

................................
................................
................................
.................

22

12.

Closing Summary

................................
................................
................................
............

23

13.

References

................................
................................
................................
......................

23

Appendix A
-

Course Descriptions of the Core Curriculum

................................
.......................

24

CprE 491 Operations Manual

................................
................................
................................
.....

26


List of Figures

Figure 1: Conceptual view
of sample design threads from Adept Proposal

................................
...

6

Figure 2 Concept Diagram

................................
................................
................................
..............

9

Figure 3 Team Effort Requirements

................................
................................
..............................

21

Figure 4 Spring Sche
dule

................................
................................
................................
...............

22

Figure 5 Fall Estimated Schedule

................................
................................
................................
..

22

Figure 6 Fall Actual Schedule

................................
................................
................................
........

22


List of Tables

Table 1 Course Topic Implementation

................................
................................
............................

8

Table 2 System Considerations

................................
................................
................................
.....

13

Table 3 Course Topics

................................
................................
................................
....................

18

4

Dec


1002

Project Plan



List of
Definitions

ADEPT
-

Applied De
sign of Practical Technology in the Computer Engineering Curriculum

Com S
-

Computer Science

Cpr E
-

Computer Engineering

Cpr E 286X
-

This is the title for the first term course that the Design Through Curriculum on
Embedde
d Systems senior design team is designing. This course is designed to be taken
during the second semester of a Computer/Electrical Engineering student's sophomore
year.

Cpr E 386X
-

This is the title for the second term course that the Design Through Curr
iculum
on Embedded Systems senior design team is designing. This course is designed to be taken
during the second semester of a Computer/Electrical Engineering student's junior year.

E E
-

Electrical Engineering

Phase I


This term is used to encompass th
e work done by Senior Design Team Dec0911, and
describes any concepts and proposals provided by as part of their project.

Executive Summary

In response to the client’s request to expand on the sophomore level learning module in the
Department of Computer Engineering of Iowa State University by creating a junior level
learning module, we are continuing
with
the
“build your own robot”

project. I
t is intended
to
be

a
one
credit design course for students wishing to
gain experience in the application of
concepts from multiple courses from the junior level curriculum.

With the versatility
and hands on nature

of robotics
,

it would serve as a basis
for the course.
We will

expand it to include task management
and
basic
scheduling, shared variable
and
resource
management, and inter
-
robot communication.

These requirements
will be applied
to a final
coordinated task

between
two

or more teams, with each
team consisting of
or
robot
.

The system that we designed for this class

will utilize an Atmel Atmega128 microprocessor,
Femto OS
preemptive
RTOS
, and a windows machine.
Each robot is equipped with a
Bluetooth Adapter Module

allowing for serial communicatio
n
.
Robots will use serial
5

Dec


1002

Project Plan


communication through the windows machine to coordinate a task chosen by the team of
students.

The goal of the lab
-
based course is for two teams of approximately four students each to
program a set of robots which will complete a
coordinated task. The task will involve
synchronized movements

and decisions, using sounds to help demonstrate the robots
communications and synchronization. The students could choose

between

several ways of
meeting

these requ
irements

and
are

encouraged to

develop

their own solution
.

Our solution consisted of two parts: a shell and an autonomous communication between the
two robots. We have a shell to allow for user interaction with the operating system, which
has capabilities to read and edit files, view a
ll processes and their current states, and starting
autonomous communication
between two robots. The communication involves

the robots
moving around synchronously and each one playing part of a song. Timing is enforced
because

the robots need to move toget
her
,

and the song needs to play close to continuously.

W
e discovered that although we could complete the project with the originally proposed Vex
platform
,

it would not meet the
requirement of having

an operating system
.

After discussing
this issue with cl
ient, we decided that it was more important to meet those requirements and
endure a

setback

than to continue on the current course. For these reasons, this document
will discuss some of the changes from the original design and
the

steps comp
leted in order to
implement
a new

design
.

Acknowledgements

This project is phase
II
of an ongoing goal to create a series of computer engineering courses
.
Our team would like to acknowledge Senior Design Team Dec0911, including Jacqueline
Bannister,

Luke H
arvey, Jacob Holen, and

Jordan Petersen for the work they completed in
phase I and the documentation they provided us to continue their work.


Problem
Statement

1.
Students in computer engineering study a wide array of topics, covering embedded systems,
comput
er architecture, and software systems. Since the department tries to prepare its
students for all areas, students must take a variety of core classes which covers the main
areas of computer engineering. However, the department finds that a number of studen
ts
struggle to see the application of what they learn and how all the field of computer
engineering work together. This issue results from the core classes not connecting to the
other areas of computer engineering
.

The lack of seeing real world application

causes
students to lose motivation, ultimately resulting in being less competitive in the job market.


6

Dec


1002

Project Plan


For this project, the
goal is to create a system to be used in the
Embedded Systems

Design
Thread

of the
ADEPT

Proposal

by

develop
ing

a system that c
an meet the junior level course
needs
:

task management and scheduling for coordination and control.

The system should also
utilize as much of the junior level curriculum as possible to help the students gain hands on
experience with a project that integrat
es the coursework they have
completed
.


Figure
1
: Conceptual view of sample design threads from
ADEPT

Proposal


Solution Approach

2.
Continuing with the inquiry
-
based learning course model
, the junior level will
motivate
students to: learn new material, provide alternate learning methodologies to address
different learning styles, increase the design experience in the Computer Engineering
program and motivate students to create a community of learners focused arou
nd problem
solving. This course will be
one

credit design lab, where students will be given the opportunity
to use the skills they have gained so far in the classroom, and apply them to a design project

in cooperative teams
.

In addition to the basic course
s taken freshmen and sophomore years that lay the foundation,
the project will challenge the students

on topics covered in a typical junior year. See
Figure 2

for more on the prerequisites of the sophomore level course.

The following
is

a l
ist of courses
a
nd topics that c
ould be addressed in this course.

E E 230. Electronic Circuits and Systems



A/D and D/A converters



Op Amps



Transistors



Electronic Circuit Design Labs


7

Dec


1002

Project Plan


Cpr E 381. Computer Organization and Assembly Level Programming



Computer Organization




Instruction Set Design



Assembly Programming



Processor Design



Memory I/O Subsystems


Cpr E 310. Theoretical Foundations of Computer Engineering



Propositional logic



Proofs



Counting and probability



Trees and graphs



Mathematical applications in C
omputer
Engineering

Com S 309. Software Development Practices



Software development management



Process models



Requirements



Coding, testing, maintenance, and
scheduling



Large Scale Software Project


Cpr E 308. Operating Systems: Principles and Practice



Multi
-
Threading



Processes



Memory Management



File Systems



I/O



Linux Experience


Com S 311. Design and Analysis of Algorithms



Algorithm design and analysis



Sorting, Searching, and Graphs



Dynamic programming and greedy
algorithms



Run time analysis



Data structure

The
due to the time constraints of this course, we had to choose the course topics to focu
s
on, while leaving the project open for expansion to cover other topics a
s needed in the
future. Table
1 shows which topics were implemented and the courses that they are
introduced to the students in.



8

Dec


1002

Project Plan


Table
1

Course Topic Implem
entation

COURSE

TOPIC

IMPLEMENTATION

Cpr E 381

Computer
Organization

Students will need to manage the configuration of the
system, and what components are turned on

Cpr E 308

Task and Memory
Management

Limited memory, multi tasking system

Cpr E 308

File

Systems

Project implements a file system on the operating system

Cpr E 308

Scheduling

Tasks require Scheduling

Cpr E 308

I/O

Program on robot must handle incoming data as well as
output to computer and other robot

Cpr E 288

Embedded System
Programming

Basic Requirement, the project is on embedded platform

Com S 311

Algorithm Design

Students will need to create an algorithm for the robots to
complete the task in a timely manor

ComS 309

Software Design
Process

Students will develop a process plan and
schedule

ComS 309

Version Control

Students will use subversion to control code changes

9

Dec


1002

Project Plan


2.1.

Concept Diagram


Figure
2

Concept Diagram


10

Dec


1002

Project Plan



Operating Environment

3.
Students in the proposed labs will work in the embedded systems computer lab. This is a
clean lab with regulated temperature, and is enclosed from the outside environment. The lab
has capacity for about 20 students, and they will be working in teams
of
two

to four

on the
robots. The robots will always stay
in the lab
and move around on the floor, which gets
cleaned when a significant amoun
t of dirt is present.


Intended Use and Users

4.
The system is intended to be used in a Design Through Curriculum on Embedde
d Systems lab
-
based course. Students will program the system and take advantage of the operating system
features to complete a coordinated task between two robots. The purpose of which, is to
experience an application of concepts from multiple junior lev
el Computer Engineering
curriculum courses.

The system will be used by students enrolled in the CprE 386X course. TAs will also us the
system in order to be familiar with the tasks the students must complete.


Assumptions and Limitations

5.
5.1.

Assumptions

5.1.1.

Students will be working in groups

of two to four

and teams will
be made up of two
groups, one for each robot

5.1.2.

The class size will not exceed the capacity of the lab and enough robots will be
available

for each group

5.1.3.

The student will ha
ve taken CprE 288, 310, 381, EE 230, ComS 228, 311 and 309.

5.2.

Limitation
s

5.2.1.

There is a cost associated with the robot hardware

and

programming
hardware

5.2.2.

The platform must support and process scheduling

5.2.3.

The robot must be standardized for eac
h team

5.2.4.

Learning and implementing the

system in seven weeks

must be

an attainable goal


End Product and Deliverables

6.
6.1.

Robot


The robot will contain all the necessary hardware
for the students
. The
original design was

based on the VEX PIC18F micro
controller
with

the hardware bundle

and the
Salvo
OS.
11

Dec


1002

Project Plan


However, we discovered this Vex platform did not meet the requirement to have an
operating system
.

After discussing this issue with client, we decided to research
and find a
new option. Table 2 lists

the

considered options.

The system that we designed for this class

will utilize a Cerebot II breakout board, with an
Atmel Atmega128 microprocessor, mounted in an iRobot Create.
The real time operating
system chosen for the system is
Femto OS.

Each robot is e
quipped with a Bluetooth Adapter
Module and can be connected to a Bluetooth enabled computer with a program to handle
communication from the user to the robots and the communication between the two robots.

6.2.

Project Tasks

6.2.1
Synchronization Tasks

Each gr
oup of students will be required to work with another group to have two robots that
perform a coordinated choreography to music, which must be played synchronously between
the two robots. Students are allowed to choose what movements the robots perform, a
s well
as the music the robots move in synchronization with.

6.2.2 Communication

The two robots will communicate with each other through a program, written by the
students, running on a windows system. The program will connect to COM ports to send and
rec
eive data to each robot across a serial Bluetooth connection. The program should also be
able to take input from the user according to the documentation provided to the students.
The student teams have discretion when determining which programming langua
ge to use to
complete this task.

6.3.

Student Documentation

Documentation defining the project for the students will be provided to aid them in
completing the project.


It will include a project requirements description and introductory
material
s

for the robot
and software.


The documentation will allow for students to quickly
gain a basic understanding of the tools they will be using to complete the project, and how
they can used to do so
. T
o not overwhelm the students and keep them on track during the
semester
, the documentation will be divided into weekly plans, which will allow them
implement the project piece by piece.

6.4.

TA Documentation

Documentation defining the project for the teaching assistants will be provided to aid them
in
guiding the students and

eva
luating
their

implementations. TAs will also develop enough
knowledge to help students taking the course, by having completed the project themselves,
to answer students questions and help them with any problems they encounter. The
documentation will explai
n how to set up the system for the evaluation.

12

Dec


1002

Project Plan


6.5.

Demonstration

A demonstration will be completed to show one
possible
solution

to meet the task
requirements
.


Because students are given the choice in movements and music, there are
many ways to complete the
required tasks.


Approach Used

7.
7.1.

Design Objectives

To ensure that the students taking this course finish with a better understanding of how the
concepts learned in core classes relate to each other, we will make the project involve specific
topics from junior level classes, with emphasis on
embedded system
s,
operating system
principles
,

and algorithm design. To add to the real
-
world approach, students will work in
teams to complete the
project
.

The objective of our design is to give stu
dents a project that incorporates

as many of the
junior level
curriculum

course concepts

as possible. This project will then help the students to
see how the courses combine together to make up their field of study.

See
Table
1: Course
Topic Implementation

for information on the specific topics implemented and the courses
they

are introduced in.

7.2.

Functional Requirements

7.2.1.

The project will show students how to apply concepts learned in other classes
.

7.2.2.

The course must be able to be reused for several semesters.

7.2.3.

The course will be based on CprE 308 (Operating Syst
ems: Principles & Practice) and
Com S 311(Algorithm Design) and will utilize
multiple tasks with priorities, file
management, algorithms, and communication
.

7.3.

Design Constraints

7.3.1.

The system platform must support threading, inter
-
process communication,

and
scheduling modification. A key difference between the junior and sophomore lab is the
incorporation of operating system concepts

and algorithm design
.

7.3.2.

L
earning the hardware and programming interface cannot be too time consuming. The
course is
only seven weeks and is intended to focus on embedded programming. A
large learning curve associated with the platform wastes time for student
development.



7.4.

Technical Approach Considerations and Results

Three different platforms were
originally
under cons
ideration for the students to be using to
complete the course. The first one considered was the National Instruments cRIO, as that is
the platform used in phase 1 for the sophomore course. The second one, the Vex Pro ARM9
13

Dec


1002

Project Plan


microcontroller, was suggested by
our advisor after showing the Vex competition game to
give ideas. The third choice was the Vex PIC microcontroller V0.5, which is the standard
platform used by Vex in their competition.

After discovering the Vex microcontroller was not a viable solution,
we began considering
new alternative options. The following

three platforms

were evaluated

for

usability in

our
project: Arduino Mega, Bug Labs BUGbase,
and Digilent Inc

Cerebot II.

Table
2

System Considerations

Board

Micro
control
ler

Operating
System

File
System

Threads

Tasks

RT Priority
Shift

Mutexes

Free

VEX Robotics
:
PIC

PICmicro

SalvoOS

?

Yes

Yes

?

?

No

Bug Labs:
Bugbase

ARM Cortex
A
-
8

Poky Linux

Yes

?

Yes

?

?

Yes

Arduino: Mega

Atmega1280

DuniOS

No

No

Yes

Yes

Yes

Yes

Digilent Inc:
Cerebot II

Atmega128

FemtoOS

Yes

No

Yes

Yes

Yes

Yes


7.4.1
.

Project

Design Considerations

We originally planned on using the Vex arena and having the students implement a soccer
-
like game. However, due to not using the Vex system, we changed

the project that the
students will complete to something more open
-
ended. They are required to implement a
project that incorporates communication and synchronized actions between two robots, file

s
ystem interaction
, multiple tasks (processes), and
algori
thm design
. As long as they show
that these topics are covered, the design of the project is up to the students


7.4.3.

Platform Considerations

Having originally planned on using the Vex system, we discovered that the platform was not
open and would not a
llow use of another operating system or non
-
Vex parts. The Compact
RIO was still not an option because we never heard back from National Instruments about
opening up some functionality of VxWorks. The Vex Pro still has no release date, which would
make acq
uiring one for our project infeasible. Another option considered was the Bug Labs
BUGbasem which has an emulator for the system. However, the emulator lacks adequate
functionality for our purposes, and the physical system is not yet available. The iRobot w
as a
viable option because we found an OS that has needed functionality and we already have one
14

Dec


1002

Project Plan


to get started working right away. Taking all of these into consideration, we ended up
choosing the iRobot for our project becau
se students would already be fam
iliar with the
hardware after having taken the sophomore embedded systems course. Faculty and TAs
would also be more familiar with the hardware, and there would be a base of code for
interfacing with the hardware.

7.4.3.1.

Compact RIO



Hardware



266 MHz



R
uns VxWorks



WiFi access point can be connected to its Ethernet



64 MB RAM



128 MB Flash



8 I/O module slots



Programmable with LabVIEW



Advantages



Have one to learn and test



We know it works for the basic functionality



NI is willing to open up at least part o
f threading and scheduling functionality



LabVIEW is used in industry, using it would be a good experience for students



Disadvantages



Not sure is NI will make all necessary functionality available or how soon they will
do so



7.4.3.2.

Vex Pro ARM9
Microcontroller

Hardware



200 MHz, 32 MB RAM, 16 MB Flash



Runs Linux 2.6



Programmable via WiFi



16 digital I/O ports



16 analog inputs



16 motor ports



Programmable with Eclipse



Advantages



Runs Linux, which has support for threading and scheduling



Students
are familiar with Eclipse and C programming with Linux libraries



Disadvantages



Vex Pro ARM9 is not yet available and no release date is known.

15

Dec


1002

Project Plan




If the similar Charmed
Labs Qwerk is chosen, we don’t know how compatible Vex
accessories



Don’t have one to te
st and mess around with



7.4.3.
3
.

PIC Microcontroller V0.5


Hardware



10 MIPS (million instructions per second)



Runs
RTOS provided by the Vex



Programmed through serial connection



1800 bytes RAM



32 kB Flash



16 I/O multipurpose I/O ports



Programmable with RobotC, MPLAB, or EasyC Pro




Advantages



Have one to learn and test



Documentation and forums show support of multitasking




Comes in a Vex robot kit, making it easier for students to put together robot and
focus on the competition.



Disadvantages



RAM and Flash are small compared to the other platform considerations



The RTOS
not possible due

to the proprietary hardware commands


7.4.3.3
.

Bug Labs BUGbase

Hardware



600 MHz, 2 GBFlash



WiFi, Bluetooth, 3G



Runs Linux 2.6


Advantages



Runs
Linux, with which students are familiar



Programmed through Eclipse



Lots of support


Disadvantages



Only recently available



Emulator exists, but has limited functionality



Adding motors and such components needs another board


7.4.3.4
.

Arduino Mega

Hardware

16

Dec


1002

Project Plan




ATmega1280 microprocessor



16 MHz



128 kB Flash



8 kB SRAM


Advantag
e
s



Plenty of memory



Simple to program


Disadvantages



No component drivers written



Available OS functionalities limited


7.4.3.
5
.

IRobot Create with Cerebot II, Atmel ATmega128, and Femto OS


Hardware



128

kB Flash



4 kB SRAM



4 kB EEPROM



16

MIPS (million instructions per second)



Already connected to the IRobot Create



Runs RTOS provided by the interface, or a third party one



Programmed
with JTAG ICE mk
-
II



Programmable with
AVR Studio





Advantages



Students
are already familiar with the iRobot and AVR Studio



Drivers for the IRobot Create have already been written that just need to be
implemented with the operating system



There is available documentation on the open source Femto OS, the Cer
ebot II,
and the IRobot Create



Sensors are already connected and available to the students to use



The department already has enough for the course set up in a lab



Disadvantages



Limited choices for operating system. None of which had all needed functional
ity



Small memory


7.5.

Testing Approach Considerations

Testing of the size of the workload for the course needs to be tested as well. In seven weeks
the students must construct the robot, become familiar enou
gh with

the programming
interface, and implement algorithm designs for the
project
. Testing this could be done two
17

Dec


1002

Project Plan


ways: keep track of how long it takes us to learn the system, and get a few volunteer students
to lear
n the system. The results could vary, because

documentation and guide
s can be
written for the course, which may
help the students learn what they need quicker.

7.6.

Recommendations for Project Continuation or Modification

There are a few risks associated with
continuation of the

project. First is that the
selected
platform has not been tested for functionality. We have only read its documentation and
related forums to find that it should have support for
most of
the
desired

functionality. A
chance exists that the system does not support a given functionalit
y in
the

way we
anticipated. Another risk is that


putting the robot together, learning the programming
interface, and implementing the algorithms for the competition are too much to ask fo
r

students to complete in a one credit, half
-
semester course.

We ha
ve already found that some of the desired functionality was not supported in the way
we anticipated. Both the file system and process spawning
require static declaration in a
configuration file for the operating system. Though files can be read and writt
en and process
priorities can be altered, new files and processes cannot be created dynamically. If asked to
qualify the Femto OS, it would have to be described as closer to a library than an operating
system. The operating system also seems to interfere

with the open interface of the iRobot,
which may require alteration of the operating system source code to fix. Because of these
risks and issues, we recommend continuing the project with an alternate board


operating
system combination.


Detailed Design

8.
8.1.

Course Design

The course is designed around the junior level courses and how to blend them into one
project. We decided to continue with the build your own robot idea, so the course has an
emphasis on embedded systems. The difficulty in designing a course

like this is time because
the students have a limited time to work on it, we needed to make sure they could get
started right away. For this reason, we decided that we would use as much premade and
prepackaged hardware.

The course will cover the
topics in

Table 3.



18

Dec


1002

Project Plan



Table
3

Course Topics



Topics

Purpose

Robot Movement Algorithms


Com S 309

Large Scale Software Project


These components will be used together to give
the students experience with a software project
that has a new
purpose, showing them how real
world software project concepts can be used in
many different situations

Multiple contributors to software project

Coding, testing, maintenance, and scheduling

Process models

Software development management

Subversion

Requirements

Cpr E 310

Trees and graphs

These components will be used together to give
the students experience with mathematical
concepts in algorithm design

Proofs

Mathematic applications

Com S 311

Algorithm design and analysis

These components will be used together to give
the students experience with algorithm creation
on embedded systems and account for another
robots algorithm.

Run time analysis

Sorting, Searching, and Graphs

Dynamic programming and greedy
algorithms

Cpr E 308

I/O systems

Linux Experience

Students will need to program the sensor input
and motor output

The robot operating system will be Linux based



Robot Communications Algorithms

Cpr E 308

Deadlocks

These components will fit together to give the
students more experience with multi threaded
systems and process management, especially on
an embedded system

Context Switches

Multi
-
Threading

Semaphores

Mutex

Com S
311

Dynamic programming and greedy
algorithms

These components fit to give
the students
algorithm design over two separate systems

Run time analysis


Robot Memory Management

Cpr E 381

I/O systems

These components fit together to show the
students how computer architecture fits into a
larger project

Instruction Set Design

Procedure calls

Stack management

Data path and control

Cpr E
308

Memory Management

These components fit together to show students
how memory is important on embedded systems

File Systems


19

Dec


1002

Project Plan


8.2.

Hardware and Software

8.2.1.

iRobot Create
-

$130

8.2.2.

AVR JTAGICE MKII
-

$300

8.2.3.

Cerebot II with ATmega128
-

$40

8.2.4.

Femto OS

8.2.5.

Robot Peripheral

8.2.5.1.

Element Direct BAM
-

$60

8.2.5.2.

LCD Sreen

8.2.6.

Programming

8.2.6.1.

AVR Studio 4

8.2.6.2.

winAVR Library

8.2.7.

Communication

8.2.7.1.

Visual Studio 2010 Express


8.3.

Testing

8.3.1.

Test Planning

8.3.1.1.

System functionality
-

Testing will be done to verify which features the platform
supports, from basic movement and using sensors to
defining tasks and writing
files.

8.3.1.2.

Learn
ing time of system
-

The time required to learn the programming interface will
be measured in order to plan out the course to make it doable in seven weeks.



8.3.2.

Test Execution

8.3.2.1.

Basic functionality
-

One test will be implemented to make sure t
he robot
functionality
works through the OS
. The test will consist of making the robot move
and checking that it can read all of its sensors. This test will also check that the
sensors are working correctly and return valid numbers.

8.3.2.2.

Operating sys
tem concepts
-

Various code segments will be written to use functions
from the api to determine what works and to try to fix what does not.

8.3.2.3.

Learning curve
-

After the student documentation is written, a few volunteer
students will be asked to read

through it and spend enough time to learn the
system. The time required for them to learn it will be recorded. This test can be
done iteratively to make documentation changes.

8.3.3.

Test Results Interpretation

8.3.3.1.

Robot functionality
-

Once the
optimization was enabled, the functions from the
open interface work correctly.

8.3.3.2.

OS functionality


Not all of the OS functions were tested, but the ones tested all
work correctly, including running multiple tasks and reading and writing files.

8.3
.3.3.

Learning Curve


Due to platform setbacks, testing with students was not
performed. However,

we feel that with proper documentation, students will not
strugg
le with the system, because

they are already familiar with it.

20

Dec


1002

Project Plan



Results from measuring how lo
ng it takes to learn the system a
n
d how effective the student
documentation seems to be will provide information on how effective the documentation is
and if the guides are too helpful or not helpful enough for the students to complete the
course in seven
weeks. If the volunteer students struggle to learn the system in a few weeks,
then more guidance will be added to the documentation.

8.4.

Documentation

Student documentation will be written to guide the students with learning the platform and
programming the ro
bot. Weekly learning modules will be written to take them in a step by
step process through
understanding the system
. The learning modules will follow the
schedule below:



Week 1:



get robot, software, and
project requirements



learn about putting this
project into a process model

and schedule




Week 2:



begin to learn about the software and programming the robot



set up subversion for the team to use



Week 3:



Load OS on the board



Robot
s should be communicating




go over algorithms in embedded systems



Week 4:




algorithm
design should be finished



Learn about timing in embedded systems



Week 5:




Finish algorithm implementation



Week 6:




Testing will begin



Week 7:



Student will demo their robots



The TA or lab instructor will have documentation on the weekly learn
ing modules in order to
know where the students are. Documentation will also cover common errors/problems the
students may encounter and give appropriate solutions.

21

Dec


1002

Project Plan



Reso
u
rce Requirement

9.
9.1.

Team

Effort Requirements


Figure
3

Team Effort Requirements

9.2.

Required Resources

9.2.1.

Hardware
: The
students
must be provided with the chassis and any components
necessary for the robot to complete its tasks.
This platform has room for expansion by
adding extra sensors or hardware additio
ns such as a robotic arm.

9.2.2.

Software
:
We have

utilize
d

open source software
throughout the system
.


The
Femto
OS, AVR Studios 4, and WinAVR
.


We used visual basic to create the robot interaction,
which can be used for free using Visual Basic 2010 Expr
ess Edition.

9.2.3.

Workstations
: Teams will need a place where they can
work on their robots
.


They
should not need to assemble any part of their robot, as the robot already has the
needed movement capabilities and sensors to use in completing the project
.

9.3.

Financial Requirements

There is no immediate

cost

associated with

implementing this
system
, because the
department already has the hardware and all the software is open source. However, the
department may need to obtain additional hardware to meet the n
eeds of all the studen
ts.
Hardware can be purchased at the following rates:

iRobot for $130, Cerebot II board for $40
and JTAG
ICE
-
mkII
programmer for $300.

27%

29%

18%

21%

5%

Documentation
Research
Implementation
Design
Hardware Testing
22

Dec


1002

Project Plan



Schedule

10.

Figure
4

Spring Schedule



Figure
5

Fall Estimated Schedule



Figure
6

Fall Actual Schedule


Project Team Information

11.
11.1.

Client

Department of Electrical and Computer Engineering (ECpE)

Dr.

David C. Jiles

dcjiles@iastate.edu

11.2.

Advisors

Dr. Akhilesh Tyagi

Associate Professor of Electrical and
Computer Engineering

tyagi@cs.iastate.edu

Jason Boyd

Lab Coordinator

jaboyd@iastate.edu



11.3.

M
e
mbers

Aisha Grieme

Computer Engineering

agrieme@iastate.edu

Jeff Melvin

Computer Engineering

jlmelvin@iastate.edu

Dane Seaberg

Computer Engineering

dseaberg@iastate.edu
23

Dec


1002

Project Plan



Summary

12.
This project’s goal is to give junior level students a bird’s eye view of their coursework by
creating a course that incorporates as much of what they
know as possible. We have done
this by creating an embedded systems course that incorporates more goals than just the
understanding of embedded systems. Through this course, we hope to motivate students to
see the purpose of their coursework and its real w
orld applications.


References

13.
Phase I documentation has been used as a reference for the entirety of our project.
We also
used several websites
.

Digilent

Inc.
, <www.digilentinc.com/>, was used
for information on the
microprocessor
.

iRobot Create
, <
www.irob
ot.com/create/>
, was used for robot images.

Femto OS
,

<www.fem
toos.org/>, was used for the api.



24

Dec


1002

Project Plan


Appendix A
-

Course Descriptions of the Core Curriculum

Cpr E 185. Introduction to Computer
Engineering and Problem Solving I. (2
-
2)
Cr. 3.

Prer
eq: Credit or enrollment in Math 141.

Description:


Introduction to Computer Engineering. Project
based examples from computer engineering.
Individual interactive skills for small and large
groups. Computer
-
based projects. Solving
engineering problems and presenting solutions
through technical reports. Sol
ution of
engineering problems using the C language.


Cpr E 281. Digital Logic. (3
-
2)
Cr. 4.

Prereq: sophomore classification. Number
systems and representation.

Description:

Boolean algebra and logic minimization.
Combinational and sequential logic des
ign.
Arithmetic circuits and finite state machines.
Use of programmable logic devices.
Introduction to computer
-
aided schematic
capture systems, simulation tools, and
hardware description languages. Design of a
simple digital system.



Cpr E 288. Embedded
Systems I: Introduction.
(3
-
2)
Cr. 4.

Prereq: Cpr E 281, Com S 207 or Com S 227.

Description:

Embedded C programming. Interrupt handling.
Memory mapped I/O in the context of an
application. Elementary embedded design
flow/methodology. Timers, scheduling
,
resource allocation, optimization, state machine
based controllers, real time constraints within
the context of an application. Applications
laboratory exercises with embedded devices.


Cpr E 308. Operating Systems: Principles and
Practice. (3
-
3)
Cr. 4.


Prereq: 381, 310.

Description
:

Operating system concepts, processes, threads,
synchronization between threads, process and
thread scheduling, deadlocks, memory
management, file systems, I/O systems,
security, Linux
-
based lab experiments.


Cpr E 310. Theoretical Foundations of
Computer Engineering. (3
-
0)
Cr. 3.

Prereq: Credit or enrollment in Cpr E 288, Com S
228.

Description:


Propositional logic and methods of proof; set
theory and its applications; mathematical
induction and recurrence
relations; functions
and relations; counting and discrete probability;
trees and graphs; applications in computer
engineering.


Cpr E 381. Computer Organization and
Assembly Level Programming. (3
-
2)
Cr. 4.

Prereq: Cpr E 281.

Description:

Introduction t
o computer organization,
evaluating performance of computer systems,
instruction set design. Assembly level
programming: arithmetic operations, control
flow instructions, procedure calls, stack
management. Processor design. Data path and
control, scalar pi
pelines, introduction to
memory and I/O systems.


E E 201. Electric Circuits. (3
-
2)
Cr. 4.

Prereq: Credit or registration in Math 267 and
Phys 222.

Description:

Emphasis on mathematical tools. Circuit
elements and analysis methods including power
and en
ergy relationships. Network theorems.
DC, sinusoidal steady
-
state, and transient
analysis. Operational amplifiers. AC power.
PSPICE. Laboratory instrumentation and
experimentation.



E E 230. Electronic Circuits and Systems. (3
-
3)
Cr. 4.

Prereq: 201, Math

267, Phys 222.

Description:

25

Dec


1002

Project Plan


Frequency domain characterization of
electronic circuits and systems, transfer
functions, sinusoidal steady state response.
Time domain models of linear and nonlinear
electronic circuits, linearization, and small signal
analy
sis. Stability and feedback circuits.
Operational amplifiers, device models, linear
and nonlinear applications, transfer function
realizations. A/D and D/A converters, sources of
distortions, converter linearity and spectral
characterization, applications.

Design and
laboratory instrumentation and measurements.


Com S 227. Introduction to Object
-
oriented
Programming. (3
-
2)
Cr. 4.

Description:

An introduction to object
-
oriented design and
programming techniques. Symbolic and
numerical computation. Recursi
on and
iteration. Modularity procedural and data
abstraction, specifications and sub typing.
Object
-
oriented techniques. Imperative
programming. Emphasis on principles of
programming and object
-
oriented design
through extensive practice in design, writing,

running, debugging, and reasoning about
programs.


Com S 228. Introduction to Data Structures. (3
-
1)
Cr. 3.

Prereq: C
-

or better in 227, credit or enrollment
in Math 165.

Description
:

An object
-
oriented approach to data structures
and algorithms.
Object
-
oriented analysis,
design, and programming, with emphasis on
data abstraction, inheritance and subtype
polymorphism. Abstract data type specification
and correctness. Collections and associated
algorithms, such as stacks, queues, lists, trees.
Searc
hing and sorting algorithms. Graphs. Data
on secondary storage. Analysis of algorithms.
Emphasis on object
-
oriented design, writing and
documenting medium
-
sized programs.



Com S 309. Software Development Practices.
(3
-
1)
Cr. 3.

Prereq: Com S 228 with C
-

or better, Com S 229
or Cpr E 211, Engl 250.

Description
:

A practical introduction to methods for
managing software development. Process
models, requirements analysis, structured and
object
-
oriented design, coding, testing,
maintenance, cost and schedule

estimation,
metrics. Programming projects.


Com S 311. Design and Analysis of Algorithms.
(3
-

1)
Cr. 3.

Prereq: 228 with C
-

or better, 229 or Cpr E 211,
Math 166, Engl 250, and Com S 330 or Cpr E
310.

Description
:


Basic techniques for design and analy
sis of
efficient algorithms. Sorting, searching, graph
algorithms, computational geometry, string
processing and NPcompleteness. Design
techniques such as dynamic programming and
the greedy method. Asymptotic, worst
-
case,
average
-
case and amortized analyse
s. Data
structures including heaps, hash tables, binary
search trees and red
-
black trees. Programming
projects.












26

Dec


1002

Project Plan


Appendix B
-

CprE 491 Operations Manual

492 Project Title:

Design Through Curriculum on Embedded Systems

492 Project Team


Students:
Jeffrey Melvin, Aisha Grieme, & Dane Seaberg


Advisor:
Dr. Tyagi


Client:

Iowa State University Department of Computer & Electrical Engineering

Authors of Document:

Zach Davis, Mohammed Rahim, Chris Reeve, & Daniel Wright



The purpose of this

project is to create a one
-
credit junior level design course. The
course would expand upon what is learned in CprE 288 and include elements from most of
the classes that students should have taken by the third year. This class would be half a
semester a
nd primarily be lab based by having a project to finish in that period. This team’s
goal is to have a project that could be used for such a course.

Functional Requirements



The project will show students how to apply concepts learned in other classes.



The
course must be able to be reused for several semesters.



The course will be based on CprE 308 (Operating Systems: Principles & Practice) and
Com S 311(Algorithm Design) and will utilize pre
-
emptive scheduling, multithreading
and algorithms.



This group has

been faced with many setbacks. The scope of the project has needed to
be changed as recently as the beginning of this fall semester. Therefore, implementation is
just now taking place, but the group is working very quickly at getting things done. They
decided to use the iRobot setup from CprE 288 in order to run everything. What the project
is composed of right now is putting the Femto OS onto the microcontroller on the iRobot
setup. The group has done this and currently has the ability to create and
execute tasks that
control the robots peripherals.

System Setup



Download & Setup of Software

o

Download WinAVR, and AVR Studio 4, and FemtoOS

o

Install both WinAVR and AVR Studio 4

27

Dec


1002

Project Plan


o

From commandline, navigate to the FemtoOS folder and run
IDE
\
install_avrstudio_workspace.bat; this will create a folder under IDE called
‘studioprojects’ and inside all the Femto_OS example files can be found



Building Projects in AVR Studio (Same procedure as for CprE 288)

o

In Project >Configuration Options set t
he device to atmega128

o

Build Active Configuration

o

Transfer program to iRobot



These are the settings to be used when the connecting computer to Robot via Bluetooth

o

57600 baud

o

8 data bits

o

no parity bits

o

2 stop bits

o

no flow control



Since implementation is j
ust now being done, there has not been much time, or much of
anything to test. I did get to observe the ability for the robot to be controlled through
Bluetooth via a phone. Other than this there was not much testing to observe.

Strengths



A lot of resear
ch was done on picking an appropriate OS to run on the microcontroller



Different hardware had been researched before picking the iRobot setup



The team adapted well to the problems they faced

Weaknesses



The team members need more experience with hardware



Even though there have been challenges it seems that the team is achieving the goals
that were set out. The Femto OS is allowing for the development of a project that will include
aspects from operating systems and algorithm classes and push students to l
earn new things.