design through the curriculum on embedded...
TRANSCRIPT
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 Jeffrey 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
Acknowledgements ..................................................................................................................... 5
Problem Statement .......................................................................................................... 5 1.
Solution Approach ............................................................................................................ 6 2.
2.1. Concept Diagram ...................................................................................................... 9
Operating Environment .................................................................................................. 10 3.
Intended Use and Users ................................................................................................. 10 4.
Assumptions and Limitations ......................................................................................... 10 5.
5.1. Assumptions ............................................................................................................ 10
5.2. Limitations............................................................................................................... 10
End Product and Deliverables ........................................................................................ 10 6.
6.1. Robot ....................................................................................................................... 10
6.2. Project Tasks ........................................................................................................... 11
6.3. Student Documentation ......................................................................................... 11
6.4. TA Documentation .................................................................................................. 11
6.5. Demonstration ........................................................................................................ 12
Approach Used ............................................................................................................... 12 7.
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
Detailed Design .............................................................................................................. 17 8.
8.1. Course Design ......................................................................................................... 17
8.2. Hardware and Software .......................................................................................... 19
3 Dec – 1002 Project Plan
8.3. Testing ..................................................................................................................... 19
8.4. Documentation ....................................................................................................... 20
Resource Requirement ................................................................................................... 21 9.
9.1. Team Effort Requirements ...................................................................................... 21
9.2. Required Resources ................................................................................................ 21
9.3. Financial Requirements .......................................................................................... 21
Schedule ......................................................................................................................... 22 10.
Project Team Information .............................................................................................. 22 11.
11.1. Client ....................................................................................................................... 22
11.2. Advisors ................................................................................................................... 22
11.3. Members ................................................................................................................. 22
Summary ........................................................................................................................ 23 12.
References ...................................................................................................................... 23 13.
Appendix A - Course Descriptions of the Core Curriculum ....................................................... 24
Appendix B - 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
4 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
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 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 1.
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.
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 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 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 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
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 Computer
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 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.
8 Dec – 1002 Project Plan
Table 1 Course Topic Implementation
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
Junior Year
Sophomore Year
Freshman Year
CprE 185- Introduction to Computer Engineering and Problem
Solving
ComS 227- Introduction to Object Oriented Programming
CprE 288- Embedded Systems I: Introduction
EE 201- Electric Circuits
CprE 281- Digital Logic
ComS 228- Introduction to Data Structures
CprE 308- Operating Systems: Principles and Practice
ComS 311- Design and Analysis of Algorithms
CprE 310- Theoretical Foundations of Computer Engineering
ComS 309- Software Development Practices
EE 230- Electronic Circuits and Systems
CprE 381- Computer Organization and Assembly Level
Programming
CprE 286X- First term “Design
Through Curriculum” course
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.
Algorithm Design
Scheduling
Processes and Threading
Second Term 386X
First Term 286X
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 amount of dirt is present.
Intended Use and Users 4.
The system is intended to be used in a Design Through Curriculum on Embedded 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 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.
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. 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 each 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 microcontroller with the hardware bundle and the SalvoOS.
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 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.
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 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
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
controller
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
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
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 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.
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 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
16 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
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 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.
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
Co
m S
30
9
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
Cp
r E
31
0
Trees and graphs These components will be used together to give
the students experience with mathematical
concepts in algorithm design Proofs
Mathematic applications
Co
m S
31
1 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
Cp
r E
30
8
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
Cp
r E
30
8
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
Co
m 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
Cp
r 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
Cp
r 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. 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.
20 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.
21 Dec – 1002 Project Plan
Resource 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 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.
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
11.2. Advisors Dr. Akhilesh Tyagi Associate Professor of Electrical and Computer Engineering [email protected]
Jason Boyd Lab Coordinator [email protected]
11.3. Members Aisha Grieme Computer Engineering [email protected]
Jeff Melvin Computer Engineering [email protected]
Dane Seaberg
Computer Engineering
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 world 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.irobot.com/create/>, was used for robot images.
Femto OS, <www.femtoos.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. 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
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:
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 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 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. (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. Searching 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 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.
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 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
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 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.