Design Through the Curriculum on Embedded Systems

Design Through the Curriculum on Embedded Systems

Dec09-11

Final Report

Client: Arun Somani

Computer Engineering Department

Advisors: Dr. Akhilesh Tyagi & Jason Boyd

Members: Luke Harvey

Jordan Petersen Jacob Holen

Jacqueline Bannister

Date:

December 11, 2009

DISCLAIMER: This document was developed as part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. The document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. Document users shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. Such use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced the document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator.

2 Dec-0911 Bound Report

Table of Content List of Figures and Tables .............................................................................................................................. 4

List of Definitions .......................................................................................................................................... 5

Executive Summary ....................................................................................................................................... 5

1 Project Plan ................................................................................................................................................ 6

1.2 Approach ................................................................................................................................................. 7

1.3 Concept Sketch ....................................................................................................................................... 8

1.3.1 ADEPT Concept Sketch .................................................................................................................... 8

1.3.2 Design through the Curriculum on Embedded Systems Concept Sketch ........................................ 9

1.4 System Block Diagram ........................................................................................................................... 10

1.5 System Description ............................................................................................................................... 11

1.5.1 CprE 286x ....................................................................................................................................... 11

1.5.1.1 Freshmen Year .................................................................................................................... 11

1.5.1.2 Sophomore Year.................................................................................................................. 11

1.5.2 Cpr E 386x ...................................................................................................................................... 12

1.5.2.1 Junior Year........................................................................................................................... 12

1.6 Operating Environment ........................................................................................................................ 12

1.7 Intended Users and Uses ...................................................................................................................... 13

1.7.1 Intended Users ............................................................................................................................... 13

1.7.2 Intended Uses ................................................................................................................................ 13

1.8 Assumptions and Limitations ................................................................................................................ 13

1.8.1 List of Assumptions ........................................................................................................................ 13

1.8.2 List of Limitations ........................................................................................................................... 13

1.9 Market and Literature Survey ............................................................................................................... 14

1.10 Deliverables ......................................................................................................................................... 14

1.10.1 Example Project ........................................................................................................................... 14

1.10.2 Hardware Platform ...................................................................................................................... 15

1.10.3 Software Tools ............................................................................................................................. 15

1.10.4 Supporting Documentation ......................................................................................................... 15

1.11 Work Plan ............................................................................................................................................ 15

1.11.1 Task List ........................................................................................................................................ 15

1.12 Project Schedule ............................................................................................................................. 15

1.12.4 Work Breakdown Structure ......................................................................................................... 16

1.14 Risks and Risk Management ............................................................................................................... 17

1.14.1 Shift in Student Interest ............................................................................................................... 17


1.14.1 Conflicts with Acquiring Tools and Hardware .............................................................................. 18

1.14.4 Future Changes to Curriculum ..................................................................................................... 18

2 System Design .......................................................................................................................................... 18

2.1 Curriculum Design Requirements (System Requirements) .............................................................. 18

2.1.1 Functional Requirements ........................................................................................................... 18

2.1.2 Non-functional Requirements ................................................................................................... 18

2.2 Functional Decomposition ................................................................................................................ 19

2.2.1 Design Thread Breakdown ......................................................................................................... 19

2.2.2 Course Outline ........................................................................................................................... 19

2.3 User Interface Specification .............................................................................................................. 19

2.4 Input/Output Specification ............................................................................................................... 20

3. Course Design (Detailed Design) ............................................................................................................. 22

3.1 Sophomore Course - 286X ................................................................................................................ 22

3.1.1 Learning Modules....................................................................................................................... 22

3.1.3 Competition Rules and Requirements ....................................................................................... 28

3.1.4 Goals........................................................................................................................................... 29

3.1.5 System Analysis .......................................................................................................................... 30

3.1.6 Competition System Design ....................................................................................................... 31

3.2 Junior Course - 386X ......................................................................................................................... 31

3.2.1 Competition Description ............................................................................................................ 32

3.2.2 Competition Rules and Requirements ....................................................................................... 33

3.2.3 Goals........................................................................................................................................... 35

3.2.3 System Analysis .......................................................................................................................... 36

4. Platform .................................................................................................................................................. 37

4.1 Platform Requirements ..................................................................................................................... 37

4.2 Hardware Specifications ................................................................................................................... 37

4.2.1 Robot Kit .................................................................................................................................... 37

4.3 Software Specifications ..................................................................................................................... 39

4.2.3 Platform Limitations ................................................................................................................... 39

4.2.3 Second Course Platform Recommendation ............................................................................... 40

5. Closing Summary ..................................................................................................................................... 41

6. Project Team Information ....................................................................................................................... 41

6.1. Client ................................................................................................................................................ 41

6.2. Advisors ............................................................................................................................................ 41

6.3. Members .......................................................................................................................................... 41


Appendix A - Student Interest Survey ......................................................................................................... 42

Appendix B - Course Descriptions of the Core Curriculum ......................................................................... 43

Appendix C – Hardware Specification Sheets ............................................................................................. 45

Appendix D – Student Survey ..................................................................................................................... 46

Appendix E – Learning Modules and Support Docs .................................................................................... 47

Appendix F – TA Evaluation Metrics ........................................................................................................... 47

List of Figures and Tables

Figure 1. Iterative Project Model .................................................................................................................. 7 Figure 2. ADEPT Concept Sketch ................................................................................................................... 8 Figure 3. Design through the Curriculum on Embedded Systems Concept Sketch ...................................... 9 Figure 4. System Block Diagram .................................................................................................................. 10 Figure 5. First Semester Tentative Project Schedule .................................................................................. 16 Figure 6. Second Semester Tentative Project Schedule ............................................................................. 17 Figure 7. Sophomore Level Course Model ................................................... Error! Bookmark not defined.7 Figure 8. System Design: Sophomore Competition .................................................................................. 321 Figure 9. Junior Level Course Model ......................................................................................................... 372 Figure 10. cRIO-9074 ................................................................................................................................... 38 Figure 11. VEX Booster Kit Parts ...............................................................................................................38 Figure 12. Xilinx Spartan-3E Starter Kit and Digilent FX2 Interface Board ………………………………………….….40

Table 1. Survey Results ............................................................................................................................... 14 Table 2 - Sophomore Level Guidance Modules .......................................................................................... 23 Table 3 - Sophomore Level Criteria and Justification ................................................................................. 28 Table 4 - Junior Level Criteria and Justification .......................................................................................... 33 Table 5 - Robotics Kit Forecast Cost ............................................................................................................ 38


List of Definitions

ADEPT- Applied DEsign of Practical Technology in the Computer Engineering Curriculum

Com S - Computer Science

Cpr E - Computer Engineering (Course listings are provided in Appendix B)

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 (Course listings are provided in Appendix B)

Executive Summary In response to the client’s request to develop a learning module for sophomore and junior students in the Department of Computer Engineering of Iowa State University, the design team decided to pursue a Build Your Own Robot project intended as a 1-credit design course. The team came to this decision based on self-interest and that of current students. The benefit of choosing robotics as a platform promises versatility and freedom in student development in a wide range of technical areas, and gives the hands-on experience students desire, as well as a physical, functional stand-alone end product. The benefit of attaching a competition provides extra motivation for students to excel in developing their project. In the two semesters, the team developed a fully functional robot that models the desired end-results of students through their developed course. Along with the robot, support documentation was developed for both the students and course administrators to successfully guide the class for the intended design curriculum. This includes any underlying platforms students may need to accomplish tasks beyond their skill-level, a project structure to assist students in completing their set goal, and the requirements set for the student’s design project.

This document includes the project plan and design details for the curriculum developed during the first semester course. System description and a testing plan for the first course are provided along with information detailing how the second coure should be developed. The information here should be sufficient enough for a future team to gain the knowledge to develop and implement the design.


1 Project Plan

Problem Statement

The Department of Computer Engineering at Iowa State University has found that underclassman students are struggling to see the connection between concepts learned within the curriculum and real world applications. Additionally the curriculum of each course tends to be compartmentalized and does not provide a bird's-eye view of the entire field. This Computer Engineering field encompasses the areas of embedded systems, computer architecture and software systems.

Need Statement

Our solution to this problem is to design an inquiry-based design thread that focuses on the use of course curriculum concepts in the area of embedded systems for the Computer Engineering department. We will do this in accordance to the ADEPT proposal, a document given to us by the department outlining what they are looking for.

As outlined in the ADEPT proposal this program should:

Motivate students to learn new material Provide alternate learning methodologies to address different learning styles Increase the design experience in the computer engineering program Motivate students to create a community of learners focused around problem solving


1.2 Approach Our team is to design an inquiry-based learning module that focuses on the use of course curriculum in the area of embedded systems for the Computer Engineering department. As outlined in the ADEPT proposal, the goals of the program are to 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. Since we did not have a clear project definition we used the iterative design model. This allowed us to start with a basic definition, build a basic system and easily expand upon the core system. The iterative design model also gave us the flexibility of reducing or expanding the scope of the project as we needed.

Figure 1. Iterative Project Model


1.3 Concept Sketch

1.3.1 ADEPT Concept Sketch

Figure 2. ADEPT Concept Sketch


1.3.2 Design through the Curriculum on Embedded Systems Concept Sketch

Figure 3. Design through the Curriculum on Embedded Systems Concept Sketch


1.4 System Block Diagram

Figure 4. System Block Diagram

Sensors

•Infrared

•Sound

•Temperature

•...

Attachments

•Motor

•Servo

•Gearbox

•Arm

•...

Competitionor

Challenge


1.5 System Description The courses described in this document will be 1-credit design lab courses. In each course the 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. The projects are similar in nature but students will be given enough freedom to use their creativity and ingenuity in order to solve the proposed problem. The projects will expose students to the design process. Students will most likely need to cooperate in teams in order to build some kind of system that will accomplish a predefined goal. Documentation and a project report will be required from the students for their projects.

1.5.1 CprE 286x

The first class, designed for sophomores in Cpr E will be Cpr E 286x. Students would be expected to have taken the following courses and apply the concepts learned in each course in order to complete the project:

1.5.1.1 Freshmen Year Cpr E 185. Introduction to Computer Engineering and Problem Solving I

C programming Problem Solving

Com S 227. Introduction to Object- oriented Programming

Object oriented programming Java programming Basic programming concepts Debugging

1.5.1.2 Sophomore Year

Cpr E 281. Digital Logic Binary Logic Sequential Logic design Finite State Machines Programmable logic devices Simulation Tools HDL programming

Com S 228. Introduction to Data Structures

Data Structures Algorithms Programming concepts Collections: stacks, queues,

lists, trees, graphs

Cpr E 288. Embedded Systems I: Introduction Embedded C Programming Memory Mapped I/O Timers, Scheduling, Resource Allocation State Machine based controllers Real Time applications Lab experience with embedded devices

E E 201. Electric Circuits Basic circuit elements Circuit Analysis methods Op Amps Ac Power PSPICE Bread boarding/Electronics lab

experience


1.5.2 Cpr E 386x The second class, designed for juniors in Cpr E would be Cpr E 386x. Students are expected to have taken the following courses as well as the 286x required courses and apply the concepts learned in each course:

1.5.2.1 Junior Year 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

Cpr E

Com S 309. Software Development Practices Software development

management Process models Requirements Coding, testing, maintenance 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

1.6 Operating Environment Students will be building their robot in a typical Computer Engineering laboratory environment. There will be 20 to 25 students in the class at one time. Students will be working in teams; the size of the teams will depend on the complexity of the project and probably range from 3 to 4 students. The robots that the students build will not be expected to operate in any type of extreme condition such as rain, high wind, and extreme heat or cold.


1.7 Intended Users and Uses

1.7.1 Intended Users

The primary users are sophomore and junior students in the Computer Engineering department and possibly some students in the Electrical Engineering department. Secondary users are teaching assistants and or advisors for the two courses. Other secondary users are the course organizer and the Computer/Electrical Engineering department.

1.7.2 Intended Uses The intended use is to provide students an alternate approach to learning through a design experience. This design process should reinforce some of the computer engineering concepts seen in the curriculum from previous courses. The program is also intended to engage students in an exciting project that captures their interest. In addition, the program we design is not intended to be excessively challenging for students as the courses will only be worth one credit hour.

1.8 Assumptions and Limitations

1.8.1 List of Assumptions

The maximum number of students in a classroom for either course will be 25 students. And the maximum number or students enrolled in either of the classes will be 80 students. As of now it is also assumed that the students in the course will be working in groups. It is also assumed that for the 286X course that the student or at least one of the students in his or her group will have taken: Cpr E 185, 281, EE 201 and Com S 227. For the 386X course it is assumed that the student or at least one of the students in his or her group will have taken Cpr E 288, 310, 381, EE 230, Com S 228, 311 and 309.

1.8.2 List of Limitations

The robot may be required to operate both indoors and outdoors. Also, the experimental courses are to be ready for student/department use by the 2010 spring semester. There will also be some type of budget for the actual courses that will limit the available hardware options.


1.9 Market and Literature Survey A survey was taken of students in Cpr E 388x Embedded Systems I and Cpr E 488 Embedded Systems Design to generate feedback on the projects that we had brainstormed. We had the students rank their top 3 preferred projects out of a list of projects. The survey is contained in the Appendix A. Table 1. Survey Results

Concept 488 Votes 388 Votes Votes Weight

Autonomous Golf Cart 1,1,3 2 5 7

IR Tracker 0 0

Miniature Robotic Arm 2,3 2,3 4 10

Sentry Gun 3 2 2 5

Build Your Own Robot 1,1,2,2,3 1,1 7 9

MP3/Video Player 1,2,2,3,3 1,3 7 15

Robotics Control Competition 1,2,2 3 4 8

Open Source Cell Phone 1,1,1,2,2,3 6 10

FPGA NES or Gaming System 1 1 1

Laser Drawing System 2 1 2

Wii Mote Racing Simulator 3 1 3

1.10 Deliverables All hardware and software licenses delivered will be sufficient for one project. We assume the client would purchase their own equipment and software for implementation of the course.

1.10.1 Example Project

Our main deliverable is a working robotics project that will combine all of the concepts in the curriculum. The project will not be an exact replica of what students are expected to make but will contain most of the components that we will require students to use. Specifically the robot is an example of what students would make for the first semester design course.


1.10.2 Hardware Platform Along with the example project, we expect to deliver the hardware platforms that are developed as well as components used for the design. This includes any potential electronics, chassis materials, sensors, etc. that have been developed for the course.

1.10.3 Software Tools

Software tools will be used and developed for the example project. We will deliver any example code, custom libraries, and hardware interfaces that are developed for the robotics project. As well as a list of external software tools that were required, such as an IDE.

1.10.4 Supporting Documentation

All developed documentation deemed useful for the operation of the course will be delivered. Specifically the team plans on delivering documentation for the development of the example project, any user guides for the tools students are expected to use, documentation for TA’s and course organizer, and any competition requirements and rules.

1.11 Work Plan

(Summary) As described in Section 2 (Approach) the work plan was modeled towards an iterative design. The plan was geared towards developing a single robotic platform and simultaneously working on components that will be present in one or both sections of the proposed design curriculum.

1.11.1 Task List

1. Research course material at each level 2. Break down skill sets for each course 3. Brainstorm project ideas 4. Research platforms for implementation 5. Propose projects for each stage 6. Implement projects 7. Document projects for student use

1.12 Project Schedule

The following is the tentative schedule modeling development and execution of a single robotic platform. It can be easily modified to accommodate two unique projects, in which case the scheduled tasks for each project can run simultaneously, or the time line can be split in proportion to the complexity of the projects. If the time line is split to accommodate separate projects, the tasks for each semester should still be completed within that semester in order to ensure that required parts may be acquired over the summer if necessary.


Milestones: Milestones were set as a marker in order to maintain a progressive schedule. This will be the same for any project schedule this team chooses to pursue.

1. Competition rules chosen/complete: March 10, 2009 2. All hardware design complete: April 9, 2009 3. All software design complete: April 9, 2009 4. First operational prototype complete: September 7, 2009 5. Robot achieves goals of project: November 1, 2009 6. Delivery of end-product: December 13, 2009

1.12.4 Work Breakdown Structure

Until a clear project definition was made any skill/resource allocations were difficult. The workload among members was distributed evenly through both semesters, at a minimum of three hours per week for each member towards the currently scheduled task(s). Work was distributed at commencement of a scheduled task. As the project progressed and technical skills were required, and work was distributed in advance to the personnel as appropriate.

Figure 5. First Semester Tentative Project Schedule


Figure 6. Second Semester Tentative Project Schedule

Figure 7. Actual Two-Semester Project Schedule

1.14 Risks and Risk Management

1.14.1 Shift in Student Interest

A major risk that may occur is the shifting interest in future student generations. This particular risk is hard to combat as it involves predicting the future. The design took careful consideration when designing the different modules and competition for the course so that at least the current generation and possible future generations will be interested in the course.

http://seniord.ece.iastate.edu/dec0911/schedule.jpg


1.14.1 Conflicts with Acquiring Tools and Hardware

Another risk was not being able to acquire the necessary hardware on time depending on our final design. The group dealt with this risk by ordering necessary hardware as soon as it was known and decided upon which hardware platform we were going to use. The group also had the advantage of the three month summer session that acted as a buffer in-between the first semester of senior design and second semester. This will allowed some leeway on delivery times when ordering parts.

1.14.4 Future Changes to Curriculum

The last major risk involved future changes to the Computer Engineering curriculum. Again this risk is hard to deal with and in reality is impossible to combat as it is no doubt going to occur at some point or another. So the best this group can do at this point in time is to focus on the current curriculum that is offered in the Computer Engineering department, as major changes to the curriculum may not happen for several years.

2 System Design We have come up with concepts for two one-credit design courses that will focus on these areas. The courses, which are described in detail in this document, are based on student designed robotics competitions. We feel that the requirements defined by the competition as well as the structure of the courses are the best options for solving the problems identified by the department based on the information detailed in this document and from student feedback.

2.1 Curriculum Design Requirements (System Requirements) From the ADEPT proposal and client feedback, the following needs were isolated for the design solution:

2.1.1 Functional Requirements

The proposed project must engage students in the area of Computer Engineering with a focus on embedded systems

New students should continue to be interested in the project from year to year The project should require a minimum of one hour of work per week for each student Students should spend on average a maximum of five hours of work on the project per week Students must also deliver a functional robot at the end of the course capable of completing

a predefined task

2.1.2 Non-functional Requirements

The project must effectively integrate knowledge expected of students for that given year Specifically, it is the Computer Engineering course curriculum that will define checkpoints

and milestones for students Must also engage student's interest and should accommodate for various levels of skill sets

and learning styles The project must involve a piece of technology that resonates currently with the students


2.2 Functional Decomposition The proposed Design through the Curriculum on Embedded Systems will take place over two semesters. Computer Engineering students should take this series during the second semester of their second and third years at Iowa State University. The courses are set up to provide a design experience for Computer Engineering students that will require them to use concepts taught in their curriculum in order to meet the requirements of the design course.

2.2.1 Design Thread Breakdown

Courses will be 15 week, 1-credit lab courses Students will be required to work in teams of size 3-4 Teams must meet weekly, during their lab time Each team will be given a robotics kit, a set of reference material and tutorials Each course will have defined competition with strict requirements that the teams must meet in

order to compete o Teams will have milestones where they will be required to demonstrate some

functionality of the robot that is specific to the competition o There should be 3-5 milestones throughout the course o Milestones will make the students demonstrate a requirement needed to compete in

the competition o Competitions and final demonstrations will take place during the last week of the

semester before finals week

2.2.2 Course Outline

1. Introduction to competition 2. Students given tutorials for all components 3. Students loaned a box of components 4. Periodic check-ups to show progress 5. Final Report 6. Competition

2.3 User Interface Specification Users will be interfacing with the course curriculum primarily through written documentation and TA assistance. The documentation will help them learn how to interface with the hardware and software in order to implement and integrate theories they have learned in previous courses, although they are challenged to learn on their own. Written documentation will be provided and accessible from the beginning of the semester and TA's will be available on a weekly basis for additional assistance.


2.4 Input/Output Specification For each course, a full set of documents will be provided in order to guide students and administrators of the course.

1. Final Project requirements: The competition rules and final robot functionality requirements. 2. Signpost Goals and Deadlines:

i. Signpost Goals: These are required to be complete and demonstrated at the

date set in order to ensure timely progression as well as demonstrate concepts

that may not be included in the final design.

1. Example:

2. Demonstrate X: Week m 3. Demonstrate Y: Week n 4. Demonstrate Z: Week p 5. ...

ii. Schedule: A complete, ideal schedule based on the senior design team's

execution and planning of the course. The schedule only serves as a model and

the end-user does not need to use the schedule.

1. Example:

2. Component 1: X days: Week Y-Z 3. Component 2: C days: Week A-B 4. etc...

3. Learning Modules: These can be used as a reference or guide for the students as they progress through the class. This includes the following.

a. Guides for students unfamiliar with hardware or software used in the course. b. Guides through implementation or integration of skills learned and can be seen as the

core guidance through the course. c. Tutorials which cover information that may be unknown to the students participating in

the course and are meant to challenge students to take their projects and learning an extra step.

4. Hardware and Software Components: 5. Students will be provided with the necessary hardware and software needed to develop and

implement solutions for the problems presented, along with data sheet specifications.

6. Complete Solution: a. A complete design solution will be provided to the administrating group to ensure the

course direction can be kept.

b. Documentation: Logs, schedules, and any recorded information the design team created during execution of the design project. This will allow others to follow and recreate a project step-by-step and provide any information that students may lack in the currently provided documents.

c. Code solutions: The solutions developed for each individual deadline goal as well as any test code developed for unit testing will be provided

d. Completed robot system: A fully functional robot for demonstration and course testing purposes.

e. Complete course/robot environment f. Course/robot environment specification


The desired output of each course will be that the students gain a broader view of the applications of integrations of their academic curriculum. This should be done by successful implementation of the requirements defined for the course. As a bonus, the student team will also have created a functional robot from base components they have learned about in previous courses.

2.4 Success Metrics (Test Plan) The success of the course is dependent on the amount of knowledge integration and interest-level students have throughout the course. The senior design team had a preliminary test of the curriculum's value by going through the execution phase of the senior design project. The time, effort, and skills used taken to fulfill each requirement of the course project will be recorded and judged. Fulfillment of the functional requirements by the robots by deadline periods will also be evaluated and more material may be needed to provide to students if tasks appear too difficult or incorporate unknown knowledge. On curriculum execution TA's will be provided with a set of evaluation criteria to monitor the student's progress, fulfillment of project deadlines, and effectiveness of students using the intended theory rather than an inferior workaround. At the end of the course students will be asked to complete a survey (see attached Appendix D) requesting their interest of the course, if it helped them gain a broader view of CprE, if they were challenged by and if they put in the effort that was desired of the course.

2.5 Prototyping

The robot developed by the senior design team was tested in the actual competition environment for their ability to perform the required tasks for the course. During this test the team determined the actual competition requirements as defined in the competition learning module. The team performed a set of module and unit tests to ensure a satisfactory end model can be created. All the devices provided to students as options for using (e.g. sonar, IR sensor) were tested with a base robot model for implementation viability and to locate any particular limitations the particular device may have in the course environment and basic robot chassis. If time permits, detailed simulation testing may be performed on the senior team's design solution to develop an additional tutorial for students interested in testing their own robots.


3. Course Design (Detailed Design)

Two courses have been designed as part of our solution to the problem. The description of these courses and competitions fall in line with the intentions of the ADEPT document and should satisfy all functional and non-functional requirements. We were unable to implement the second course, 386X, during our final semester. This was due to time constraints and hardware limitations that are described in section 4 (Platform) of this document. This detailed design gives the requirements of a course idea for the second semester that could be used by ADEPT or another senior design team in order to complete an implementation of the second competition. We also give a new platform recommendation in this section detailing the platform we would use if we were able to have more resources available to us.

3.1 Sophomore Course - 286X In the sophomore level course, CprE 286X, students will develop a robot from a kit of components and will focus on participating in a competition at the end of the semester. Students will be given a set of tutorials on the specific components that they will be unfamiliar with and will be given time to become comfortable with them. The competition has requirements that will require students to apply their computer engineering knowledge without explicitly telling them to do so or leading them though like traditional labs.

3.1.1 Learning Modules Students will be presented with the large picture at the beginning of the course and will be able to start designing and creating their robot immediately. In order to help the students though the specific areas of robotics that they may not be familiar with, we will provide tutorials on different aspects of robot creation with our platform. In the table below the tutorials are listed along with a justification of why the students would be able to use the tutorial and how it will benefit them to look at it.


Table 2 - Sophomore Level Guidance Modules

Topics Tutorial Task Use/Justification

Battery

RLC Circuits

Bread boarding

Voltage Dividers

Construct a voltage divider circuit on a breadboard, given a set of input voltages, so that the circuit correctly produces various output voltages. These output voltages will be used by various sensors on the robot. Discuss power issues in robotics.

Students will have to use a basic understanding of RLC circuits and bread boarding in order to complete their design. Students will also have to know how to test their design.

This module is necessary for understanding the use of the power supply design of the robot.

cRio

cRIO

LabVIEW

Setup the cRIO in LabVIEW and create a small program in that ties one of the analog outputs on the board to one of its inputs and see if the signal is received correctly. Repeat with digital I/O.

Students may have no prior experience with LabVIEW or the cRIO and will have to use their digital logic and C skills in order to use LabVIEW. This module is necessary because students will need to be familiar with both technologies.


Sensors

Datasheets

Timers

Interrupts

Review the data-sheet for a particular sensor (such as a bump sensor) and the data-sheet for the cRio’s analog/digital I/O module and demonstrate the proper way to connect the sensor to one of the I/O module’s pins. The students will be given code in LabVIEW that they will have to modify in order interface with the sensor. However, this code will use while statements to read signals from the sensor, therefore students will be encouraged to implement an interrupt based system instead. The interrupt driven design should be a slightly faster solution than the busy wait approach.

Students will need a basic understanding of interrupts in order to complete requirements in the competition. They also should be able to recognize the importance of removing the polling while statements from code as the robot will be receiving input from multiple sensors and it is not feasible to use a busy wait approach for everything because of limited processor time. Additionally, in order for students to even be able to connect the sensor to the robot they will have to be able to read the appropriate datasheets for the sensor and the I/O module.

This module is necessary for completing the interfacing between the robot and input sensors.

Wireless Communication

Buffering

API Interfacing

Polling/Interrupts

Wireless Comm. Protocols

Encoding/Decoding

Set up a wireless connection between the cRIO and a PC using the selected wireless protocol. Seeing as the lab is only 1 credit and time is therefore limited, students will be given partially completed code to complete in order to set up the wireless connection. The code that they have to fill in will deal with the message buffering aspect of wireless communication. However students again will have to recognize the importance of interrupts, whenever a message is received it has to be handled as soon as possible. Students will also have to understand how the encoding and decoding of a message works.

A tutorial or API outlining many of these concepts and the Bluetooth communication protocol will be given to the students as a guide. The wireless communication may be something that is new to students, which is why we will have to walk them through much of this but many of the concepts can still be touched upon. Students should be familiar with using API's and external libraries.

This task is necessary for setting up some type of communication protocol between the robot and the PC so that status and debugging information can be sent from the robot to the PC.


Servos

Binary Logic

Datasheets

Pulse-Width Modulation

Torque (Physics)

Review the specifications on the datasheet for the supplied servos and determine the amount of forward motion they will be able to produce given certain PWM and voltage. From this calculate the maximum weight the robot can be to achieve a certain speed. Once this is complete students will be directed to correctly configure the cRio to provide the appropriate input for the servos.

It is important that the students see that there is an upper bound to how hard they can push the servos which is why we have them do the physics calculations. Students will also have a better understanding of how servos on robots work.

This task is necessary in setting up the robot’s core source of mobility.

Control

Finite State Machines

Scheduling

Polling/Interrupts

Timers

Robot will perform some task after it is signaled to do so. This will include programming a robot to act as a finite state machine where it can transition from a stand-by state to one of many moving states (forward, backwards, turning left, turning right) and then back to stand-by. A button or sensor will be used as input to change from state to state. PC via Bluetooth could also be used. The robot would perform the designated task for a certain amount of time, and would show students to learn how to implement a timer.

The final design of the robot will most certainly implement some type of state machine for the final competition, which is why the concept is introduced here. In the final competition the robot will most likely have several different complex states that it can be in (such as a defensive state if it knew it were being followed or targeted, or one of many offensive states depending on the current state of the competition)

This module is necessary in getting students familiar with how to control their robot.

Vision

Hardware Acceleration

HDL Programming

/O Handling

Refactoring

Code Analysis

Students will be directed to analyze a program in LabVIEW that processes input from a Smart Camera. Some type of vision recognition will be done which will be very resource intensive. The runtime considerations will be presented as will the benefits of hardware acceleration. An updated program that performs the vision recognition much more efficiently and in addition certain functions will have been moved into hardware. Students will then again analyze the code and possibly fill in parts of code that is missing to complete the basics of the vision recognition.

Vision recognition is going to be used in the final competition and from past experience this would be a good spot to introduce the ideas of hardware acceleration and code analysis. Students may have seen this briefly in previous classes but not in this much detail. With this being said, however, most of the code for this portion of the robot will be given to them.

This task is necessary for setting up some type of integration between the robot and the Smart Camera.


Competition

Algorithms

Game Theory

All the topics listed above

As with many games, such as chess, there is some type of “optimal” solution to winning the competition based on the current state of the game. Although it will not be required of students to fully analyze the competition using game theory, the idea will nonetheless be introduced (probably using chess as an example) giving the students some idea of how we want them to go about programming the robot for the competition.

All the topics listed above will be utilized during the final competition. In order for students to have a good chance in winning the competition they will need to utilize the idea of game theory to produce an efficient algorithm for the competition.

This task is necessary for bringing together all the concepts learned above into one overall system.


3.1.2 Competition Description

The game requires that the robots color a whiteboard with their assigned color in a given amount of time. To add complexity, two robots will compete on the same whiteboard at a time, the assigned color will vary, and obstacle(s) can be added to the playing field. Success of the student's project will be based on fulfillment of base requirements, quality of the finished product, and performance in the competition. Individual Base Requirements for entry

Straight line navigation Ability to turn Ability to avoid an obstacle Manual stop Wireless communication Boundary detection

The environment for the game will take place on a dry erase board or single-color material appropriate for the size and anticipated performance of the robot. The playing board will be divided up into a grid of squares that will be used as an objective for the robots. Obstacles will be included that cover up some portion of the board as well as a wall border for the robots to detect as shown in the figure to the right.

A similar board design to the one in the figure will be used to test each robot in its ability to fill as many squares as possible in a timed event. In the competition, two robots will compete head to head against each other to try and fill as many squares dominantly with its color as possible. Each robot will be allowed to be equipped with a marker and an eraser that can be used to erase enemy robot lines. The robots can connect wirelessly to a camera placed above the field, to be used as feedback as well as their sensors to avoid walls, obstacles, and the opposing robot while filling in as many squares as possible during the competition time. The competition will be set up as a one-time elimination tournament. Bots will be ranked based on their solo performance to get their seed spot and the TA will be responsible for assigning the won squares to each side. Teams will only be allowed to use the supplied large components, such as sensors, motors, etc.

The game is scored by how much color has been covered on the playing field at the end of the time limit. The field will be divided up into smaller sectors and a certain percentage of that sector must be colored in order to get the 'point' for that area. How the field is sectored is unknown to the students so they cannot tailor a single strategy to avoid one obstacle. This introduces different approaches on how to maximize coverage using the given coloring instrument. In competition, not only is complexity added by the factor of another player and color, but the students can develop methods that may test/break other team's algorithms and they must develop their robot to handle other team's complicated strategies as well. (For instance, if a team chooses to make a broken line, the competing robot may not be able to track and erase or follow that path). Students must describe their game strategy in their final report.

Figure 7 – Sophomore Level Course Model


3.1.3 Competition Rules and Requirements

The following table describes the specific rules and justifications for those rules as they would pertain to getting students to apply their computer engineering knowledge. All of the specifications discussed in the competition description are also required; these are just the more specific requirements.

Table 3 - Sophomore Level Criteria and Justification

Topics Requirement Justification

Limited Battery

EE Concepts (Power, PWM, Voltage

Dividers)

Data Sheets

EE Lab experience

Using large set of sensors, motors, servos, etc and a limited battery. Students must choose which components to use as well as power issues with a limited battery. If your battery dies in the competition there is no restarting.

The battery supplied to the students will have a limited battery life. This will require them to consider power issues that are inherent in embedded systems. They will have to control the power consumption of their robots by choosing motor speed and the amount of sensors. This requires students to make decisions based on power limits given when using batteries in embedded systems.

Must locate starting gate from unknown

orientation

Memory Mapped I/O

Datasheets

Polling

I/O Handling

State Machines

Each robot will not start out on the course but a distance away from the course. The robot must autonomously navigate itself to the opening of the course to begin. The competition will start once the robots are allowed to start finding the course.

Robots are not allowed to mark any area outside the playing field. Doing so results in disqualification from the competition.

Teams will start out a distance away from the playing field and must navigate successfully onto the field to begin the game. It will be important to get there as quickly as possible because the game begins once they are allowed to start finding the field. This requires them to use their ultrasonic sensor or tradeoff with time delay in the competition.

Robots will not be allowed to mark any area outside of the playing area. This will require students to use actuators to raise and lower their markers, making the control of the robot more complex.

Robots will be penalized for

collisions

Interrupts

Polling

Interfacing with software

Data Structures

If a robot collides with a wall or obstacle during the competition they will be penalized X number of squares during the final scoring.

In the case of a robot collision, the team determined at fault (by the TA) will be penalized a larger amount of squares during the final scoring.

This requires students to use interrupts and other concepts to avoid a penalty.

This reinforces the concepts above but requires the students to have a 360 degree "view" using the sensors and forces them to be more aware of the enemy’s location encouraging better algorithms and use of the smart camera.


Robots must halt immediately when

given done command


Interrupts

Robot must stop and display stop LED once a command is issued. One square per second of score after the done command is issued will be deducted from the final square count.

This provides an easy way to control the time limit in a competition and requires students to implement wireless communication as well as interrupts. Once students have wireless working they would be able to receive information from the camera making both advantageous without forcing them to do so.

Robots must report status, orientation,

location


Software Interfacing

Sensors

Robot must display information about its status to a PC.

This requires students to implement wireless communication as well as encourage vision use. This will also turn into a resource for game algorithm development and game theory

Refer to the Dry-Erase Bot Competition learning module for more information, including exact rules, tips, and recommendations.

3.1.4 Goals

A major goal of our project is to construct a course focusing on embedded systems that will incorporate as many concepts as possible that students will have learned in previous courses. The competition described above contains strict requirements in order to force students to use concepts that should have been learned previously. The following is a list of required courses offered by the Iowa State Computer Engineering Department that computer engineering students are required to take and thus should have taken by the time they take CprE 286X. What we have done is mapped the topics covered by the competition to the actual course that the topic was covered in.

Freshman Year CprE 185. Introduction to Computer Engineering and Problem Solving I

C programming (LabVIEW, control interface, hardware software interfacing with sensors) Problem Solving (design aspect, freedom of choice to make best robot to win competition)

Com S 227. Introduction to Object-oriented Programming Basic programming concepts ( if statements/loops/case statements/functions) Debugging (inherent in developing a design)

Sophomore Year CprE 281. Digital Logic

Binary Logic(using LabVIEW, interfacing with sensor and hardware) Sequential Logic design(using LabVIEW) Finite State Machines(see 288) Programmable logic devices (HDL programming and control logic)


Simulation Tools(LabVIEW can simulate signals) HDL programming (Hardware acceleration of vision recognition, FPGA interface for setting up

and routing module information)

Com S 228. Introduction to Data Structures Data Structures (Use graphs and tress for path algorithms, queues for buffering) Algorithms ( path finding, vision recognition, algorithm analysis to determine runtime balance) Programming concepts (Vision recognition interfacing, dataflow, API compliance to interface

with premade software)

CprE 288. Embedded Systems I: Introduction Embedded C Programming (algorithm and hardware control software, camera interface, sensor

interfaces) Memory Mapped I/O (modules, sensors, camera will have memory mapped I/o) Timers, Scheduling, Resource Allocation (Managing sensor input, camera input and control

outputs) State Machine based controllers (Control Algorithms, decision making, game control states) Real Time applications(Managing feedback from multiple sensors and camera, Controlling

hardware) Lab experience with embedded devices (interaction with cRio)

EE 201. Electric Circuits Basic circuit elements (Use of basic electronic components by interfacing with LeDs, sensors,

etc) Ac Power (PWM to control servos and actuator) Bread boarding/Electronics lab experience (Reading Data sheet/ installing sensors/ experience

with instrumentation such as DMMs and scopes)

3.1.5 System Analysis Upon completion of the course students should be able to clearly understand the applications of what they are learning in their classes. We hope that students taking this first 286x course will feel encouraged to continue on and take the 386x course. The students should be given enough information in order to complete their robots during the course. It is also a goal of the course to engage the students interest in embedded systems and a robotics competition seems to be a logical choice in our experience as students ourselves.


3.1.6 Competition System Design Our final competion setup is shown in the diagram below. A NI-Smart Camera was mounted above the playing field. It monitors the colors and robots on the playing field. There is a competition server that runs on a PC using LabVIEW. It processes information from the camera and sends competition data to the robots. This server also provides as a mechanism for controlling whether or not a competition is running. The robots are free to use this information as they please, but may only run when the server has indicated the competition as active.

Figure 8 - System Design: Sophomore Competition

3.2 Junior Course - 386X In the sophomore level course, CprE 386X, students will build upon the ideas used during the first semester. As with the first course a large scale robotics competition will be held at the end of the semester to test that the robot meets the given requirements. This competition, described later in greater detail, has also been specifically designed so that students will be forced to use concepts that were learned in previous courses. Less guidance will be given this time around as the bulk of the course will revolve around the design and implementation aspect of the robot's competition strategy.


3.2.1 Competition Description The competition involves a single robot traversing a course in search of an "armed" bomb. The main objective of the robot is to find the bomb, defuse the bomb in under a certain amount of time, and return to the starting location in under a certain amount of time. Some curve balls are thrown into the course to make the overall goal more challenging, and to force students to use some of the concepts learned in previous courses. One being that the layout of the course is not known so the robot's movement must be completely autonomous. Secondly there are multiple "dummy" bombs on the course that the robot is specifically not to disarm. A penalty will be assessed if an incorrect bomb is disarmed. A means of determining one bomb from another will be provided and is described in the rules and requirements section. Thirdly, the actual process of disarming the bomb will be very specific and involve several subcomponents, each of which can be done in one of two ways; a slower non optimal way and a faster more efficient way. Since the disarming of the bomb is going to be timed the student is forced to use the faster more efficient implementation. More restrictions for the competition are outlined in the following section.

Individual Performance Requirements for Entry All requirements from CprE 286X Ability to disarm bomb Report status to control PC whenever possible

The following picture is an example of how the course might be laid out.

Figure 9 - Junior Level Course Model


3.2.2 Competition Rules and Requirements

Table 4 - Junior Level Criteria and Justification

Topics Requirement Justification

Bomb detection

Signal Analysis

Hand Shaking

Filters

Robot must come within a certain distance of the bomb in order to begin defusing it. Each bomb will be emitting a low strength wireless signal that will be able to be detected by the robot. In order to determine how close they are to the bomb, the robot will have to analyze the strength of the signal and compare that value to a pre-determined value that is known to be associated with a distance that is under the required distance (D). Additionally the robot will not be able to start disarming the bomb until it has confirmed with the bomb that it is within the required distance.

Since this is the only way that the robot will be able to detect the bomb, students will be required to do some type of signal analysis in order to determine where the bomb is and how close they are to the bomb. Additionally a predefined protocol on how they are to communicate with the bomb will be given to students. Using this hand-shaking protocol will be the only way for the robot to begin defusing the bomb, which forces them to use it.

Defuse the correct bomb

Signal Analysis

Filters

There will be multiple bombs on the course; the robot must only defuse the bomb it is assigned to.

As the detectable and identifiable medium, each bomb will be emitting its own wireless signal on a unique frequency. The robot will have to detect which bomb it is at based on the strength of the signal at that bomb’s particular frequency. In order to isolate a bomb’s assigned frequency the robot will have to filter out all other frequencies. The robot will be allowed to defuse any of the bombs on the course but, as stated before, the robot will be assigned only one bomb to defuse, that of which it is supposed to find in the course. If the robot defuses an incorrect bomb a time penalty of ‘X’ will be assessed at the end of its run.

In order defuse the correct bomb the robot must be able to perform the signal analysis and filtering properly. The robot in theory could defuse each bomb but if this happens it will be obvious by the grader that the student(s) in that team did not perform this task as required, at which time a time penalty will be assessed. It is important that the robot is able to perform this task because not only will the robot be given an additional time penalty if it defuses an incorrect bomb, but the robot will have spent a lot of time in actually going through the process of defusing the bomb(s).

Bomb must be defused in under a certain amount of time (This requirement is broken down into the following 3 requirements)

Disarm mode

Tasks & Threading

Process Scheduling

Finite State Machines

The robot must switch to a disarm mode where it disables any unnecessary processes or tasks running on the processor.

The robot must send a message to the bomb indicating it is in disarm mode and that it is going to begin disarming the

Since this is a timed operation and the robot will not have to move or monitor sensors or perform any other major operations for that matter, except disarm the bomb, students should be able to recognize that in order to save time the process spawned to handle the disarming should be set a high priority. Since


bomb. The time it takes to disarm the bomb will begin once this signal is received.

the time it takes to disarm the bomb starts when the bomb receives this signal, the robot must be able to perform this task.

Must determine if bomb is a threat

Data Structures

List Searching

In order to disarm the bomb the robot has to correctly determine whether or not the bomb is a threat and report that information back to the bomb.

Students will be given a very large list of bombs (on the order of tens of thousands). Each of these bombs will have a value associated with it indicating whether the bomb is a threat or not. The robot will then have to search through this “key-and-value look-up table” to determine the threat status of the bomb and report its findings to the bomb. A time penalty will be assessed if the robot reports an incorrect threat status.

Since the time it takes to determine whether or not a bomb is a threat is going to be added to the overall time to disarm the bomb it forces students to take this search time into consideration. As stated earlier the table given to them is going to be extremely large and will be intentionally pre-sorted by keys, this will allow students to use some type of searching algorithm to decrease the O(n) search time (binary search or other list searching algorithm).

Disarm bomb

FPGA

HDL Programming

Hardware Acceleration

Encoding/ Decoding

Algorithms

In order to disarm the bomb the robot must decode a signal sent by the bomb.

The robot should send the decoded message back to the bomb after it is done. The time it takes to disarm the bomb will stop once the bomb receives the correctly decoded signal.

The decoding will intentionally involve a lot of floating point operations. This opens students up to the option of moving these operations into hardware in order to decrease the overall time it takes to decode the bomb.

Report status and location

Tasks & Threading

Data Structures (Message Queues)

Interrupts

Deadlocks / Mutexes

Whenever possible the robot must report location and current status information back to a control PC.

Since this consumes a lot of CPU time the students should be able to recognize the benefits of moving the communication operation into its own task. Now that the robot has multiple threads running, some type of scheme will need to be implemented so that the threads can communicate with each other quickly, safely and efficiently.

Return back to start in under a certain amount of time

Algorithms

Autonomy

After the correct bomb is defused the robot must return back to its starting location.

The robot will be required to complete the overall course in under a certain amount of time. The course design will not be known

While this time limit will not be as excessively strict as the time limit associated with disarming the bomb, it will still challenge students to develop an efficient course traversal algorithm. Additionally, since the outlay of the course will not be known, the robot must operate completely


to students or the robots ahead of time. autonomously with no outside input. This also means the students will not be able to hardcode the movement of the robot, since they will be unaware of the exact layout of the course.

Boundary & object detection

Memory Mapped I/O

Datasheets

Interrupts

Robot must not go outside the course boundary or run into any objects accidentally while traversing the course.

A time penalty will be assessed every time the robot runs into an object.

This requirement forces students to interface with the given sensor(s) so that the robot does not hit an object or go outside the course boundaries.

3.2.3 Goals A major goal of our project was to construct a course focusing on embedded systems that will incorporate as many concepts as possible that students will have learned in previous courses. The competition described above contains strict requirements in order to force students to use concepts that should have been learned previously. The following is a list of required courses offered by the Iowa State Computer Engineering Department that computer engineering students are required to take and thus should have taken by the time they take CprE 386X. What we have done is mapped the topics covered by the competition to the actual course that the topic was covered in. Some topics have been carried over from the previous semester, which is why they are not listed here.

E E 230. Electronic Circuits and Systems

Signal Analysis

Filters

CprE 381. Computer Organization and Assembly Level Programming

Assembly Programming Memory I/O Subsystem FPGA

CprE 310. Theoretical Foundations of Computer Engineering

Propositional logic Counting and probability Trees and graphs Mathematical applications in CprE


Com S 309. Software Development Practices

Software development management Process models Requirements Coding, testing, maintenance, and scheduling Large Scale Software Project

CprE 308. Operating Systems: Principles and Practice

Multi-Threading Deadlocks / Mutexes Processes and Tasks Scheduling Memory Management I/O

Com S 311. Design and Analysis of Algorithms

Algorithm design and analysis Sorting, List Searching Run time analysis Data structures

3.2.3 System Analysis Seeing as the courses are to focus on the areas of embedded systems and were to incorporate as many concepts from previous courses, naturally, we felt the best platform choice for the two courses was a robotics platform. We felt it would be much easier to incorporate more areas of embedded systems using a robotics platform versus our other initial options, such as the open source cell phone idea. Even though many of the other courses offered in the Computer Engineering Department already use some type of robotics platform in their labs we still felt students will still be interested in the CprE 286X and CprE 386X courses mainly due to the fact that the students will be getting hands on experience in building the robot from the ground up, which is something they do not experience in any of the other Computer Engineering courses. In addition, the previous two sections have identified individual requirements for the second semester course itself and have also justified how those requirements fulfill the given topics that students should be familiar with.


4. Platform

4.1 Platform Requirements Flexible The Design through the Curriculum courses use completely different competitions and is possible that the competition requirements change. It is also expected that each team has a different robotic design and implementation. In order to accommodate so much variability the robotics platform used for the Design through the Curriculum needs to allow a lot of flexibility for robotic designs. Easy to Use Students will be expected to spend 2-4 hours per week on their robot. This means that there are a limited number of man hours to be spent. Since the intent of these courses is to emphasize various topics taught in other classes, it is important that the platform be easy to use and understand. Ease of use will allow the students to focus on their design and all the concepts they need to bring.

4.2 Hardware Specifications

The NI Compact RIO (cRIO) is a good choice for the robotics platform. It has an on board FPGA, controller, and has slots for 8 modules. These features give the teams a lot of freedom with what they can do. The cRIO was chosen because of it is flexible, customizable and easy to use.

4.2.1 Robot Kit The robotics kit includes the core platform needed for designing the robot. It includes a cRIO and various modules. There should be 6 kits, or enough to accommodate an entire lab section. Students will design their chassis and peripherals around this core kit. Since NI has already donated 1 kit, only 5 more are needed. This brings the overall cost for robot kits to $25,550.

Figure 10 - cRIO-9074


Table 5 - Robotics Kit Forecast Cost

Components

Item Part Number Price Quantity Total

Vex Chassis Kit 276-2232 $200 1 $200

VEX Robotics Wheel Kit 276-2164 $30 1 $30

Servo s HS-422 $17 2 $34

DC Motors GHM-01 $22 4 $88

IR Sensor GP2D120 $13 1 $13

Custom PCB + 12v Battery CHUN-2420C-4.2Ah $218 1 $218

Accelerometer S-300-28017 $9 3 $27

Bump Sensors Pack FRS-V-276-2159 $13 2 $26

Sonar Sensor S-10-EZ4 $30 1 $30

Dry Erase Board - $35 1 $35

Wireless Router/Adapter ASUS WL-330g and WL-520GC $102 1 $102

4.2.2 Team Kit

Each team will be given their own kit to build a chassis. Students will not be forced to use all of the parts, but they still need to create a robot that can meet the requirements of the competitions. Any of the basic electronic elements that are needed by students (LEDs, wires, etc.) can be obtained from the university. Students may also use their lab kits from EE 201 and EE 230. The team kits will be composed of chassis pieces and peripheral components. The peripherals are various sensors and controls that may be attached to the chassis of the robot. The chassis will not be

preconstructed. Students will be given all of the pieces, and they are expected to design a chassis that will hold the cRIO and any peripherals they choose to use.

Figure 11 - VEX Booster Kit Parts


4.3 Software Specifications

Choice and Justification Along with all of the hardware components, students will need software to program and control their robot. By choosing the cRIO platform students will be able to take advantage of a lot of the NI software. By utilizing NI's graphical programming language, LabVIEW 8.6, students are able to easily interface and control the different module on the cRIO. The LabVIEW FPGA and LabVIEW Embedded toolkits that extend off of LabVIEW 8.6 make it easy to customize the cRIO's onboard FPGA and microcontroller. A big advantage to using LabVIEW, is that different portions of implementation may be done graphically or programmed at a different level. LabVIEW allows the user to link to C libraries and LabVIEW FPGA allows the FPGA to be programmed graphically or using VHDL. The amount of flexibility that NI software brings to the table is important because students will be given the freedom to implement their robot in their own way. Software Components

LabVIEW 8.6 - Programming tool to use NI hardware. LabVIEW FPGA - Graphical tool for programming FPGAs. LabVIEW Embedded -Programming tool for microcontrollers. NI-RIO 3.0 - Driver software needed for NI-RIO devices. This is needed for the cRIO to be

recognized and to be programmed. Measurement & Automation Explorer (MAX) - NI tool for checking and testing devices

connected to the system and network. This is useful for verifying that a device can be detected and has basic functionality.

NI Vision Development Module - Needed for the Smart Camera. Vision Builder A.I. - Needed for the Smart Camera.

4.2.3 Platform Limitations

After committing to the cRIO and learning more about the platform we realized that some areas of the platform are not ideal. We were initially under the impression that the cRIO was much more open and allowed more access to the system than we came to discover. Because of this, we decided to only use the cRIO to implement the first semester course and give a recommendation as to why the cRIO is not a good platform for the second semester course.

The cRIO is only programmable using the LabView software and requires the use of a .vi file in order to control it. We were originally under the impression that we would have microcontroller access and would be able to do such things as allow interrupts, do low level programming and control register values. It is possible to implement the entire robot control algorithm using labview and not be required to use any c programming at all. In our implementation we were able to force this by using a c library function call node.

In order for students to apply their operating systems knowledge to the course we were under the impression that we would have access to the VxWorks RTOS. We later found that while the cRIO does use VxWorks internally, it does not allow modification, control, or direct interaction. This means that


students would be unable to implement a multi-threaded application, scheduling algorithm, and many other concepts that are covered in CprE 308.

4.2.3 Second Course Platform Recommendation

Xilinx Spartan-3E Starter Kit - $189 Based on the platform complications and experience that we had with the NI cRIO we have decided that a FPGA or microcontroller development board would be sufficient to implement all of the requirements of the second design course. Our recommendation to a future project would be the Xilinx Spartan-3E Starter Kit.

From the Xilinx website, “The Spartan-3E FPGA Starter Kit is a complete development board solution giving designers instant access to the capabilities of the Spartan-3E family. Complete kit includes board, power supply, evaluation software, resource CD (application notes, white papers, data sheets, etc.), and USB cable.”

The Spartan-3E board can run a Microblaze processor on the FPGA allowing students to modify their processor in order to use their digital logic and computer architecture skills learned in CprE 381 and CprE 281 their classes. They will also be able to use the FPGA for their own hardware implementations. It can also run an embedded version of linux, uClinux. Junior students will have already taken CprE 308, Operating Systems and will be familiar with linux. Using this they can control all aspects of the operating system and use threads, scheduling, etc to their fullest. The board itself contains a large toolbox of connectors and interface options including: serial, USB, PS2, Ethernet, LCD display, switches, rotary encoder and I/O pins.

Digilent FX2 Interface Board - $20

This board connects with the Spartan-3E board using the FX2 interface connection and will provide multiple I/O pins and connectors for use in a robotics system.

Figure 12 - Xilinx Spartan-3E Starter Kit and Digilent FX2 Interface Board


5. Closing Summary By catering to current student interest and making use of the versatility of a robotic platform, the team is certain that the developed project will successfully give students an integrated view of their coursework as well as provide early design experience and stimulate independent learning. The team plans to use an iterative design approach to develop a model for students, and is confident the complete curriculum and a model platform can be delivered within the proposed budget by the end of Fall Semester, 2009.

6. Project Team Information

6.1. Client Department of Electrical and Computer Engineering (ECpE) Dr. Arun Somani 391C Durham Center Ames, IA 50011 Tel: (515) 294-0442 Fax: (515) 294-1152 E-mail: [email protected]

6.2. Advisors

Dr. Akhilesh Tyagi Associate Professor of Electrical and Computer Engineering 391B Durham Center Ames, IA 50011 Fax: 515-294-8432 Office Phone: 515-294-4396

Jason Boyd Lab Coordinator 2101A Coover Hall Ames, IA 50011 Tel: 515-294-1256 E-mail: [email protected]

E-mail: [email protected]

6.3. Members Jacqueline Bannister Electrical Engineering 57 Linden Devitt Tel: 515-572-3761 E-mail: [email protected]

Luke Harvey Computer Engineering 4404 Lincoln Swing St. #8 Tel: 712-539-2575 E-mail [email protected]

Jacob Holen Computer Engineering 150 Campus Ave. #2 Tel: 612-998-3775 E-mail: [email protected] Jordan Petersen Computer Engineering 3204 Lettie St. Tel: 712-579-0013 E-mail: [email protected]


Appendix A - Student Interest Survey

This survey is going to be used to develop a new design project course at Iowa State University as part of the Curriculum Though Embedded Systems senior design team's project. We appreciate your feedback and feel free to include any project ideas you would have enjoyed and found interest in while you were an underclassman.

Please pick three projects below that you find the most interesting and exciting. Rank 1-3, with 1 being the most interested. _____ Concept: Autonomous Golf Cart

Description: Autonomous golf cart that would follow sidewalks on campus. Could complete certain tasks like giving people rides to areas on campus via touch screen interface, delivering packages, etc.

_____ Concept: IR tracker Description: Create an object tracking system to be used like a mouse or some other controller. _____ Concept: Miniature Robotic Arm Description: Students would create a mini robotic arm from scratch to be able to complete some task. _____ Concept: Sentry Gun

Description: Create servo controls and object detection and tracking to create a sentry gun like device that would be setup somewhere in the field and operate independent of human control.

_____ Concept: Build Your Own Robot

Description: Students would have a package of microcontrollers, motors, servos, sensors, electronics, hardware, etc. Develop a robot to do some task such as sumo, laser tag, navigate a course, autonomy

_____ Concept: Mp3/Video Player Description: Create Mp3 and video player including many features that are popular in consumer electronics today. _____ Concept: Robotics Control and Competition

Description: Students would create wireless Bluetooth control for a robotic platform. Install their own selected sensors and compete with other robots based on a series of challenges.

_____ Concept: Open Source Cell Phone

Description: Students would design a working GSM cell phone from a development board. Would have to use a LCD display or touch screen display and could include both mp3 and video decoding.

_____ Concept: FPGA NES or Gaming System Description: Nintendo. On a FPGA. _____ Concept: Laser Drawing System Description: Develop controls and software for a laser drawing system for the side of buildings and walls. _____ Concept: Large Format Printer/Etcher Description: Create control hardware and software for making a plotter or other large format etching tool. _____ Concept: Wii Mote Racing Simulator

Description: Wii Mote would control a race car in a simple GUI race car simulator. Students would create the race car's control software and part of the Bluetooth communication module between the PC and Wii Mote.

Cool idea's we have missed: Thank you for your feedback! -Dec 09-11 Senior Design Team


Appendix B - 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 NP completeness. 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 C – Hardware Specification Sheets Compact RIO 9073: http://www.ni.com/pdf/products/us/2008-10370-161-101-D.pdf Analog Input Module: http://www.ni.com/pdf/products/us/c_series_ao.pdf Analog Output Module: http://www.ni.com/pdf/products/us/c_series_ao.pdf Digital I/O Module: http://www.ni.com/pdf/manuals/374069e.pdf Smart Camera: http://www.ni.com/pdf/products/us/cat_ni_1742.pdf Bluetooth Serial Adapter: http://www.iogear.com/product/GBS301/ Rechargeable 24V Battery: http://www.batteryspace.com/index.asp?PageAction=VIEWPROD&ProdID=2961 Steppers: http://www.trossenrobotics.com/sparkfun-stepper-motor.aspx Servos: http://www.trossenrobotics.com/store/p/3291-Hitec-HS-475HB-standard-hobby-servo.aspx DC Motors: http://www.trossenrobotics.com/store/c/3047-Lynxmotion.aspx IR Sensors: http://www.trossenrobotics.com/sharp-ir-distance-sensor-gp2d120.aspx Black/White Sensors: http://www.trossenrobotics.com/store/p/5785-Single-Line-Following-Sensor.aspx Accelerometer: http://www.trossenrobotics.com/store/p/5384-Memsic-2125-Accelerometer.aspx Bump Sensors: http://www.trossenrobotics.com/store/p/3118-VEX-Bumper-Switch-Kit.aspx Sonar Sensor :http://www.trossenrobotics.com/maxbotix-lv-maxsonar-ez4.aspx Linear Actuator/Solenoid: http://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?langId=-1&storeId=10001&catalogId=10001&productId=1919473& Compass: http://www.trossenrobotics.com/hitachi-hm55b-compass-module.aspx VEX robotics structure products: http://www.vexrobotics.com/vex-booster-kit.shtml VEX wheel kit: http://www.vexrobotics.com/vex-robotics-wheel-kit.shtml VEX track kit: http://www.vexrobotics.com/vex-robotics-tank-tread-kit.shtml

http://www.ni.com/pdf/products/us/2008-10370-161-101-D.pdf

http://www.ni.com/pdf/products/us/c_series_ao.pdf

http://www.ni.com/pdf/products/us/c_series_ao.pdf

http://www.ni.com/pdf/manuals/374069e.pdf

http://www.ni.com/pdf/products/us/cat_ni_1742.pdf

http://www.iogear.com/product/GBS301/

http://www.batteryspace.com/index.asp?PageAction=VIEWPROD&ProdID=2961

http://www.trossenrobotics.com/sparkfun-stepper-motor.aspx

http://www.hitecrcd.com/servos/show?name=HS-422

http://www.trossenrobotics.com/store/c/3047-Lynxmotion.aspx

http://www.trossenrobotics.com/sharp-ir-distance-sensor-gp2d120.aspx

http://www.trossenrobotics.com/store/p/5785-Single-Line-Following-Sensor.aspx

http://www.trossenrobotics.com/store/p/5384-Memsic-2125-Accelerometer.aspx

http://www.trossenrobotics.com/store/p/3118-VEX-Bumper-Switch-Kit.aspx

http://www.trossenrobotics.com/maxbotix-lv-maxsonar-ez4.aspx

http://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?langId=-1&storeId=10001&catalogId=10001&productId=1919473&

http://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?langId=-1&storeId=10001&catalogId=10001&productId=1919473&

http://www.trossenrobotics.com/hitachi-hm55b-compass-module.aspx

http://www.vexrobotics.com/vex-booster-kit.shtml

http://www.vexrobotics.com/vex-robotics-wheel-kit.shtml


Appendix D – Student Survey

Student Survey:

1. Did you like the course?

2. Did you recognize or use any concepts from other classes you’ve taken at ISU during this course, particularly:

Cpr E 281 – Digital Logic:

Com S 228 – Intro to Data Structures:

Cpre E 288 – Embedded Systems Intro:

EE 201 – Electric Circuits:

Cpr E 185 – Intro to Cpr E & Problem Solving:

Com S 227 – Intro to OOP:

Other courses:

3. Are there any concepts/components that you would like to see implemented in the course that currently aren’t?

4. Anything you would change about the course (platforms, competition, difficulty, …)?

5. The goal of this course was to provide you(the students) a creative way of using everything you’ve learned up until now and applying it to a possible real-world application. Has the course been helpful in giving you that experience, and if not, how can we make it so the course can?

Thank you for taking the survey. :)


Appendix E – Learning Modules and Support Docs

*See attached files in Microsoft Publisher format and Adobe PDF.

Appendix F – TA Evaluation Metrics

Student Performance Metrics

Never/Bad

Always/Good

1 2 3 4 5

Game Performance Starts via wireless signal Stays within course boundaries No Collisions Bot reports status, orientation, loc Effective Game Algorithm Bot Speed Stops on game end Students can explain

configuration

Hardware Proper use of equipment Shock Test* Students can explain

configuration

Software Organized code Documentation, OR Students can explain robot

TA Comments

* Drop from 4" or give gentle shove - Testing connectivity, structural integrity


Documents

Design Through the Curriculum on Embedded Systems