Problem Statementseniord.ece.iastate.edu/.../docs/fall/Final_Report.docx · Web viewArithmetic...

Design Through the Curriculum on Embedded Systems

Dec10-02

Final Report

Client:Computer Engineering Department

Advisors:Dr. Akhilesh Tyagi & Jason Boyd

Members:Aisha GriemeJeffrey MelvinDane Seaberg

Date:December 6, 2010

1 Dec – 1002 Project Plan

Contents

Contents..................................................................................................................................... 2

List of Figures..............................................................................................................................3

List of Tables...............................................................................................................................3

List of Definitions........................................................................................................................4

Executive Summary.................................................................................................................... 4

Acknowledgements....................................................................................................................5

1. Problem Statement.........................................................................................................5

2. Solution Approach...........................................................................................................6

2.1. Concept Diagram......................................................................................................9

3. Operating Environment.................................................................................................10

4. Intended Use and Users................................................................................................10

5. Assumptions and Limitations........................................................................................10

5.1. Assumptions...........................................................................................................10

5.2. Limitations............................................................................................................. 10

6. End Product and Deliverables.......................................................................................11

6.1. Robot..................................................................................................................... 11

6.2. Project Tasks..........................................................................................................11

6.3. Student Documentation.........................................................................................11

6.4. TA Documentation.................................................................................................11

6.5. Demonstration.......................................................................................................12

7. Approach Used..............................................................................................................12

7.1. Design Objectives...................................................................................................12

7.2. Functional Requirements.......................................................................................12

7.3. Design Constraints.................................................................................................12

7.4. Technical Approach Considerations and Results....................................................12

7.5. Testing Approach Considerations...........................................................................16

7.6. Recommendations for Project Continuation or Modification................................17

8. Detailed Design............................................................................................................. 17

8.1. Course Design........................................................................................................ 17


8.2. Hardware and Software.........................................................................................20

8.3. Testing....................................................................................................................20

8.4. Documentation......................................................................................................21

9. Resource Requirement..................................................................................................22

9.1. Team Effort Requirements.....................................................................................22

9.2. Required Resources...............................................................................................22

9.3. Financial Requirements..........................................................................................22

10. Schedule........................................................................................................................23

11. Project Team Information.............................................................................................23

11.1. Client......................................................................................................................23

11.2. Advisors..................................................................................................................23

11.3. Members................................................................................................................23

12. Closing Summary...........................................................................................................24

13. References.....................................................................................................................24

Appendix A - Course Descriptions of the Core Curriculum.......................................................25

CprE 491 Operations Manual....................................................................................................27

List of Figures

Figure 1: Conceptual view of sample design threads from Adept Proposal...................................6Figure 2 Concept Diagram.............................................................................................................9Figure 3 Team Effort Requirements.............................................................................................21Figure 4 Spring Schedule..............................................................................................................22Figure 5 Fall Estimated Schedule.................................................................................................22Figure 6 Fall Actual Schedule.......................................................................................................22

List of Tables

Table 1 Course Topic Implementation............................................................................................7Table 2 System Considerations....................................................................................................13Table 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.

1. Problem Statement

Students in computer engineering study a wide array of topics, covering embedded systems, computer architecture, and software systems. Since the department tries to prepare its students for all areas, students must take a variety of core classes which covers the main areas of computer engineering. However, the department finds that a number of students struggle to see the application of what they learn and how all the field of computer engineering work together. This issue results from the core classes not connecting to the other areas of computer engineering. The lack of seeing real world application causes students to lose motivation, ultimately resulting in being less competitive in the job market.


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

2. Solution Approach

Continuing with the inquiry-based learning course model, the junior level will motivate students to: learn new material, provide alternate learning methodologies to address different learning styles, increase the design experience in the Computer Engineering program and motivate students to create a community of learners focused around problem solving. This course will be one credit design lab, where students will be given the opportunity to use the skills they have gained so far in the classroom, and apply them to a design project in cooperative teams.

In addition to the basic courses taken freshmen and sophomore years that lay the foundation, the project will challenge the students on topics covered in a typical junior year. See Figure 2 for more on the prerequisites of the sophomore level course. The following is a list of courses and topics that could be addressed in this course.

E E 230. Electronic Circuits and Systems A/D and D/A converters Op Amps

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 IMPLEMENTATIONCpr E 381

Computer Organization

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

Cpr E 308Task and Memory Management

Limited memory, multi tasking system

Cpr E 308 File Systems Project implements a file system on the operating systemCpr E 308 Scheduling Tasks require Scheduling

Cpr E 308 I/OProgram on robot must handle incoming data as well as output to computer and other robot

Cpr E 288Embedded System Programming

Basic Requirement, the project is on embedded platform

Com S 311 Algorithm DesignStudents will need to create an algorithm for the robots to complete the task in a timely manor

ComS 309Software 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

Figure 2 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

3. Operating Environment

Students in the proposed labs will work in the embedded systems computer lab. This is a clean lab with regulated temperature, and is enclosed from the outside environment. The lab has capacity for about 20 students, and they will be working in teams of two to four on the robots. The robots will always stay in the lab and move around on the floor, which gets cleaned when a significant amount of dirt is present.

4. Intended Use and Users

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.

5. Assumptions and Limitations

5.1. Assumptions5.1.1. Students will be working in groups of two to four and teams will be made up of two

groups, one for each robot5.1.2. The class size will not exceed the capacity of the lab and enough robots will be

available for each group5.1.3. The student will have taken CprE 288, 310, 381, EE 230, ComS 228, 311 and 309.

5.2. Limitations5.2.1. There is a cost associated with the robot hardware and programming hardware5.2.2. The platform must support and process scheduling5.2.3. The robot must be standardized for each team5.2.4. Learning and implementing the system in seven weeks must be an attainable goal


6. End Product and Deliverables

6.1. Robot The robot will contain all the necessary hardware for the students. The original design was based on the VEX PIC18F microcontroller with the hardware bundle and the SalvoOS. 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 Tasks6.2.1 Synchronization TasksEach 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 CommunicationThe 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 DocumentationDocumentation 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 DocumentationDocumentation 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. DemonstrationA 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.

7. Approach Used

7.1. Design ObjectivesTo 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 Requirements7.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 ResultsThree 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

BoardMicro

controllerOperating

SystemFile

SystemThreads

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 ConsiderationsWe 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 ConsiderationsHaving 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 BUGbaseHardware

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 MegaHardware

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 ConsiderationsTesting 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 ModificationThere 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.

8. Detailed Design

8.1. Course DesignThe 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 PurposeRobot Movement Algorithms

Com

S 3

09

Large Scale Software ProjectThese 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 projectCoding, testing, maintenance, and schedulingProcess modelsSoftware development managementSubversionRequirements

Cpr E

310 Trees and graphs These components will be used together to give

the students experience with mathematical concepts in algorithm design

ProofsMathematic applications

Com

S 3

11

Algorithm design and analysisThese components will be used together to give the students experience with algorithm creation on embedded systems and account for another

robots algorithm.

Run time analysisSorting, Searching, and GraphsDynamic programming and greedy algorithms

Cpr E

308 I/O systems

Linux Experience

Students will need to program the sensor input and motor output

The robot operating system will be Linux based

Robot Communications Algorithms

Cpr E

308

DeadlocksThese components will fit together to give the students more experience with multi threaded

systems and process management, especially on an embedded system

Context SwitchesMulti-ThreadingSemaphoresMutex

Com

S

311

Dynamic programming and greedy algorithms These components fit to give the students

algorithm design over two separate systemsRun time analysis

Robot Memory Management

Cpr E

381

I/O systemsThese components fit together to show the

students how computer architecture fits into a larger project

Instruction Set DesignProcedure callsStack managementData path and control

Cpr E

30

8 Memory Management These components fit together to show students how memory is important on embedded systemsFile Systems


8.2. Hardware and Software8.2.1. iRobot Create - $1308.2.2. AVR JTAGICE MKII - $3008.2.3. Cerebot II with ATmega128 - $408.2.4. Femto OS8.2.5. Robot Peripheral8.2.5.1. Element Direct BAM - $608.2.5.2. LCD Sreen8.2.6. Programming8.2.6.1. AVR Studio 48.2.6.2. winAVR Library8.2.7. Communication8.2.7.1. Visual Studio 2010 Express

8.3. Testing8.3.1. Test Planning8.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 Execution8.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 Interpretation8.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. DocumentationStudent 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.


9. Resource Requirement

9.1. Team Effort Requirements

27%

29%

18%

21%

5%

Documentation Research Implementation Design Hardware Testing

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 RequirementsThere 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.


10.Schedule

Figure 4 Spring Schedule

Figure 5 Fall Estimated Schedule

Figure 6 Fall Actual Schedule

11.Project Team Information

11.1. Client Department of Electrical and Computer Engineering (ECpE) Dr. David C. [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 GriemeComputer Engineering [email protected]

Jeff MelvinComputer Engineering [email protected]

Dane SeabergComputer [email protected]


12.Summary

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

13.References

Phase I documentation has been used as a reference for the entirety of our project. We also used several websites. Digilent Inc., <www.digilentinc.com/>, was used for information on the microprocessor. iRobot Create, <www.irobot.com/create/>, was used for robot images. Femto OS, <www.femtoos.org/>, was used for the api.


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 Systems492 Project Team

Students: Jeffrey Melvin, Aisha Grieme, & Dane SeabergAdvisor: 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 Softwareo Download WinAVR, and AVR Studio 4, and FemtoOS


o Install both WinAVR and AVR Studio 4o 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 atmega128o Build Active Configurationo Transfer program to iRobot

These are the settings to be used when the connecting computer to Robot via Bluetootho 57600 baudo 8 data bitso no parity bitso 2 stop bitso 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.


Problem Statementseniord.ece.iastate.edu/.../docs/fall/Final_Report.docx · Web viewArithmetic...

Documents

Transcript of Problem Statementseniord.ece.iastate.edu/.../docs/fall/Final_Report.docx · Web viewArithmetic...