Design Through the Curriculum on Embedded Systemsseniord.ece.iastate.edu/projects/archive/dec1002/... · Embedded Systems Dec10-02 Final Report Client: Computer Engineering Department

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


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


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


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


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.


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


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.


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


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


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.


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.


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


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


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.


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


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


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.


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


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.


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.


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


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

[email protected]

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

[email protected]


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.


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:


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.


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


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.

Documents

Design Through the Curriculum on Embedded Systemsseniord.ece.iastate.edu/projects/archive/dec1002/... · Embedded Systems Dec10-02 Final Report Client: Computer Engineering Department