Final Design Report - ECpE Senior Design

advertisement
Design Through the Curriculum on
Embedded Systems
Dec10-02
Final Report
Client:
Computer Engineering Department
Advisors:
Dr. Akhilesh Tyagi & Jason Boyd
Members:
Aisha Grieme
Jeffrey Melvin
Dane Seaberg
Date:
December 6, 2010
1
Dec – 1002 Project Plan
Contents
Contents ....................................................................................................................................... 2
List of Figures ............................................................................................................................... 3
List of Tables ................................................................................................................................ 3
List of Definitions ......................................................................................................................... 4
Executive Summary...................................................................................................................... 4
Acknowledgements ..................................................................................................................... 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 Tasks ........................................................................................................... 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.
Functional 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
2
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 Schedule ............................................................................................................... 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
3
Dec – 1002 Project Plan
List of Definitions
ADEPT- Applied Design 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
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 sophomore
year.
Cpr E 386X - This is the title for the second term course that the Design Through Curriculum
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 the 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. It 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 communication. Robots will use serial
4
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 requirements 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 all 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 together, and the song needs to play close to continuously.
We 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 client, 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 completed 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 Harvey, 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
Students in computer engineering study a wide array of topics, covering embedded systems,
computer 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 students
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.
5
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 developing a system that can 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 integrates the coursework they have completed.
Figure 1: Conceptual view of sample design threads from ADEPT Proposal
Solution Approach
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 around 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 courses 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 list of courses
and topics that could be addressed in this course.
E E 230. Electronic Circuits and Systems
 A/D and D/A converters
 Op Amps
6
 Transistors
 Electronic Circuit Design Labs
Dec – 1002 Project Plan
Cpr E 381. Computer Organization and Assembly Level Programming
 Computer Organization
 Processor Design
 Instruction Set Design
 Memory I/O Subsystems
 Assembly Programming
Cpr E 310. Theoretical Foundations of Computer Engineering
 Propositional logic
 Trees and graphs
 Proofs
 Mathematical applications in Computer
Engineering
 Counting and probability
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
 File Systems
 Processes
 I/O
 Memory Management
 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 focus
on, while leaving the project open for expansion to cover other topics as needed in the
future. Table 1 shows which topics were implemented and the courses that they are
introduced to the students in.
7
Dec – 1002 Project Plan
Table 1 Course Topic Implementation
COURSE
TOPIC
IMPLEMENTATION
Cpr E 308
Cpr E 308
Computer
Organization
Task and Memory
Management
File Systems
Scheduling
Cpr E 308
I/O
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
Cpr E 381
Cpr E 308
ComS 309
ComS 309
8
Software Design
Process
Version Control
Students will need to manage the configuration of the
system, and what components are turned on
Limited memory, multi tasking system
Project implements a file system on the operating system
Tasks require Scheduling
Program on robot must handle incoming data as well as
output to computer and other robot
Students will develop a process plan and schedule
Students will use subversion to control code changes
Dec – 1002 Project Plan
2.1. Concept Diagram
Junior Year
Second Term
386X
EE 230- Electronic Circuits and Systems
CprE 381- Computer Organization and Assembly Level
Programming



Algorithm Design
Scheduling
Processes and Threading
CprE 310- Theoretical Foundations of Computer Engineering
ComS 309- Software Development Practices
CprE 308- Operating Systems: Principles and Practice
ComS 311- Design and Analysis of Algorithms
Students will use the above
concepts to complete a similar
project to the first term with new
components based on classes
taken during their Junior Year.
The goal will be a robot that
interacts with another to complete
a task.
Sophomore Year
CprE 281- Digital Logic
ComS 228- Introduction to Data Structures
CprE 288- Embedded Systems I: Introduction
First Term
286X
EE 201- Electric Circuits
CprE 286X- First term “Design
Through Curriculum” course
Freshman Year
CprE 185- Introduction to Computer Engineering and Problem
Solving
ComS 227- Introduction to Object Oriented Programming
Figure 2 Concept Diagram
9
Dec – 1002 Project Plan
Operating Environment
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 amount of dirt is present.
Intended Use and Users
The system is intended to be used in a Design Through Curriculum on Embedded Systems labbased 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 level 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.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 have taken CprE 288, 310, 381, EE 230, ComS 228, 311 and 309.
5.2. Limitations
5.2.1.
5.2.2.
5.2.3.
5.2.4.
There is a cost associated with the robot hardware and programming hardware
The platform must support and process scheduling
The robot must be standardized for each team
Learning and implementing the system in seven weeks must be an attainable goal
End Product and Deliverables
6.1. Robot
The robot will contain all the necessary hardware for the students. The original design was
based on the VEX PIC18F microcontroller with the hardware bundle and the SalvoOS.
10
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 equipped 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 group 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, as 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
receive 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 language 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
materials 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. To 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 evaluating 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 explain how to set up the system for the evaluation.
11
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.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 systems, 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 students 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 Systems: 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. Learning 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 consideration 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
12
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
Micro
controller
Operating
System
VEX Robotics:
PIC
PICmicro
SalvoOS
?
Yes
Yes
?
?
No
Bug Labs:
Bugbase
ARM Cortex
A-8
Poky Linux
Yes
?
Yes
?
?
Yes
DuniOS
No
No
Yes
Yes
Yes
Yes
FemtoOS
Yes
No
Yes
Yes
Yes
Yes
Board
Arduino: Mega Atmega1280
Digilent Inc:
Cerebot II
Atmega128
File
RT Priority
Threads Tasks
Mutexes Free
System
Shift
7.4.1. Project Design Considerations
We originally planned on using the Vex arena and having the students implement a soccerlike 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
system interaction, multiple tasks (processes), and algorithm 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 allow 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 acquiring 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 was a
viable option because we found an OS that has needed functionality and we already have one
13
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 because students would already be familiar 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
 Runs 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 of 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.
14
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 test 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
15
Dec – 1002 Project Plan

ATmega1280 microprocessor
 16 MHz
 128 kB Flash
 8 kB SRAM
Advantages
 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 Cerebot 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 functionality
 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 enough with the programming
interface, and implement algorithm designs for the project. Testing this could be done two
16
Dec – 1002 Project Plan
ways: keep track of how long it takes us to learn the system, and get a few volunteer students
to learn the system. The results could vary, because documentation and guides 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 functionality 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 for
students to complete in a one credit, half-semester course.
We have 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 written 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.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.
17
Dec – 1002 Project Plan
Table 3 Course Topics
Purpose
Com S 311
Robot Movement Algorithms
Large Scale Software Project
Multiple contributors to software project
These components will be used together to give
Coding, testing, maintenance, and scheduling the students experience with a software project
that has a new purpose, showing them how real
Process models
world software project concepts can be used in
Software development management
many different situations
Subversion
Requirements
Trees and graphs
These components will be used together to give
the students experience with mathematical
Proofs
concepts in algorithm design
Mathematic applications
Algorithm design and analysis
Run time analysis
Sorting, Searching, and Graphs
Dynamic programming and greedy
algorithms
These components will be used together to give
the students experience with algorithm creation
on embedded systems and account for another
robots algorithm.
Cpr E 308
Cpr E 310
Com S 309
Topics
I/O systems
Linux Experience
Students will need to program the sensor input
and motor output
The robot operating system will be Linux based
Cpr E
308
Cpr E 381
Com S
311
Cpr E 308
Robot Communications Algorithms
18
Deadlocks
These components will fit together to give the
Context Switches
students more experience with multi threaded
Multi-Threading
systems and process management, especially on
Semaphores
an embedded system
Mutex
Dynamic programming and greedy
These components fit to give the students
algorithms
algorithm design over two separate systems
Run time analysis
Robot Memory Management
I/O systems
Instruction Set Design
These components fit together to show the
students how computer architecture fits into a
Procedure calls
larger project
Stack management
Data path and control
Memory Management
File Systems
These components fit together to show students
how memory is important on embedded systems
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. Learning 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 the 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 system 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
struggle with the system, because they are already familiar with it.
19
Dec – 1002 Project Plan
Results from measuring how long it takes to learn the system and 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 robot. 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
 Robots 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 learning modules in order to
know where the students are. Documentation will also cover common errors/problems the
students may encounter and give appropriate solutions.
20
Dec – 1002 Project Plan
Resource Requirement
9.1. Team Effort Requirements
Documentation
Research
Implementation
Design
Hardware Testing
5%
21%
27%
18%
29%
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 additions such as a robotic arm.
9.2.2. Software: We have utilized 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 Express 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 needs of all the students.
Hardware can be purchased at the following rates: iRobot for $130, Cerebot II board for $40
and JTAG ICE-mkII programmer for $300.
21
Dec – 1002 Project Plan
Schedule
Figure 4 Spring Schedule
Figure 5 Fall Estimated Schedule
Figure 6 Fall Actual Schedule
Project Team Information
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. Members
Aisha Grieme
Computer Engineering
agrieme@iastate.edu
22
Jeff Melvin
Computer Engineering
jlmelvin@iastate.edu
Dec – 1002 Project Plan
Dane Seaberg
Computer Engineering
dseaberg@iastate.edu
Summary
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 world applications.
References
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.irobot.com/create/>, was used for robot images.
Femto OS, <www.femtoos.org/>, was used for the api.
23
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.
Prereq: 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. Solution 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 design.
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
24
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 to 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 pipelines, 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 energy 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:
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
analysis. 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 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 analysis 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 analyses. Data
structures including heaps, hash tables, binary
search trees and red-black trees. Programming
projects.
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. Recursion 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. (31) 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.
Searching and sorting algorithms. Graphs. Data
on secondary storage. Analysis of algorithms.
Emphasis on object-oriented design, writing and
documenting medium-sized programs.
25
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 and 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

26
Download & Setup of Software
o Download WinAVR, and AVR Studio 4, and FemtoOS
o Install both WinAVR and AVR Studio 4
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 the 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 just 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 research 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 learn new things.
27
Dec – 1002 Project Plan
Download