Download - Idp Manual

Transcript
Page 1: Idp Manual

.DEPARTMENT OF ENGINEERING

1B Integrated Design Project

2013-14

MOBILE ROBOT

LOGISTICSSYSTEM DESIGN

MECHANICAL DESIGNELECTRONIC DESIGNSOFTWARE DESIGN

P.J.G. LongP.R. PalmerD.D. Symons.

Issue date : 20/09/13

Page 2: Idp Manual

The Department would like to thank the many companies, organisations and individuals whohave supported the course since its inception in 1996, in particular:-

Boeing - www.boeing.comCambridge-MIT Institute - www.cambridge-mit.orgiEndian - www.iendian.comMartin-Jones - www.martin-jones.comNHK - www.nhk.or.jpOnecall - onecall.farnell.comOmax - www.omax.comPTC - www.ptc.comSMC - www.smcpneumatics.co.ukToby Churchill Ltd - www.toby-churchill.comTTP - www.ttpgroup.com

Robin Jackson (1937 - 1995) was a major influence in the development and implementation of theIB Integrated Design Project and was responsible for much of the Logistics and Electronics

material contained within.

Page 3: Idp Manual

Contents

LOGISTICS 4

L.1 Introduction 4

L.2 Aims and Objectives 4

L.3 Project Organisation 4

L.3.1 Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

L.3.2 Work Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

L.3.3 Timetable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

L.4 Deliverables / Assessed Work 7

L.4.1 First Presentation - [ 15% Marks - Team ] (Individual attendance required) . . . . 8

L.4.2 First Report - [ 20% Marks - Team ] . . . . . . . . . . . . . . . . . . . . . . . . 8

L.4.3 Initial Bill of Materials - [ 5% Marks - Sub-Team ] . . . . . . . . . . . . . . . . . 9

L.4.4 Design Acceptance - [ *15% Marks - Sub-Team ] . . . . . . . . . . . . . . . . . . 10

L.4.5 Basic Functionality Demonstration - [ upto 9% Marks - Team/Sub-Team ] . . . . 11

L.4.6 Final Presentation - [ 15% Marks - Sub-Team ] . . . . . . . . . . . . . . . . . . . 12

L.4.7 Competition - [ 15% Marks - Team ] . . . . . . . . . . . . . . . . . . . . . . . . . 12

L.4.8 Robot Quality - [ 6% Marks - Sub-Team ] . . . . . . . . . . . . . . . . . . . . . . 12

L.4.9 Final Report [ 65% Marks - Individual, 35% Marks - Team ] . . . . . . . . . . . 13

L.5 Additional Logistics Information and Equipment Provided 14

L.5.1 The 1B Robot Desktop Environment . . . . . . . . . . . . . . . . . . . . . . . . . 14

L.5.2 Penalties for Lateness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

L.5.3 Laboratory Notebook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

L.5.4 Inventory and House Keeping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

L.5.5 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

L.6 Suggestions and Feedback 15

SYSTEM DESIGN 16

D.1 Introduction 16

D.2 Design Process 16

D.3 Overview of Tasks 16

D.4 Characterisation Tests 18

MECHANICAL DESIGN 19

M.1 Introduction 19

M.2 Design Process and Overview of Tasks 19

M.2.1 Vehicle Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Page 4: Idp Manual

M.2.2 Motors and Pneumatic Actuators . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

M.3 Robot Manufacturing 20

M.3.1 Workshop Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

ELECTRICAL DESIGN 21

E.1 Introduction 21

E.1.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

E.1.2 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

E.2 Design Process 21

E.3 Design Tasks 22

E.3.1 Defining Circuit Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

E.3.2 Circuit Embodiment Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

E.3.3 Design Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

E.3.4 Printed circuit boards (PCBs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

E.3.5 Circuit Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

E.3.6 Circuit testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

E.3.7 System Integration and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

SOFTWARE DESIGN 25

S.1 Introduction 26

S.2 Methodology for Producing Software Systems 26

S.3 Introduction to the use of the Software Library 28

S.3.1 A Simple Example Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

S.3.2 The Workstation Programming Environment . . . . . . . . . . . . . . . . . . . . . 29

S.3.3 The Microprocessor Programming Environment . . . . . . . . . . . . . . . . . . . 30

S.4 Tasks to be performed 31

S.4.1 Formulating the Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . 31

S.4.2 Initial Tasks and Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

S.4.3 Other Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

KIT LIST 33

K.5 Introduction 33

K.5.1 Mechanical Materials/Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

K.5.2 Electrical Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

K.5.3 Software Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Individual Timesheet 36

Page 5: Idp Manual

1B Integrated Design ProjectMobile Robot Project Logistics

L.1 Introduction

Modern design often requires an integrated system to be designed by a multi-disciplinary team. Thisdesign, build and test project is intended to simulate this situation. The disciplines represented areElectronic, Mechanical and Software Engineering.

This document describes the overall aims and objectives of the Integrated Design Project and setsout the logistics for its organisation. It also in some cases (for example the sections on reportwriting) provides an overview to be read in conjunction with more specialised material in the otherdocuments.

The project involves designing and building a model Autonomous Guided Vehicle (AGV) or mobilerobot from a kit of parts. It is a mechanical device with associated electronic circuits and controlsoftware. The combination is often categorised by the term mechatronics. The task to be undertakenby the AGV is given in a separate problem statement issued at the start of the project.

Credit is given for the planning and execution of the design and construction process, the quality ofthe complete vehicle and its performance of the set task. Performance is assessed in a competitionheld shortly after each four week project period.

The documentation in this handout plus a large amount of other material is available on the IDPWeb site: http://www.eng.cam.ac.uk/DesignOffice/idp/.

L.2 Aims and Objectives

The underlying aim of the project is to develop system design skills. In parallel, it aims to developdesign project management skills and to create an appreciation of the interaction between designand production.

The project should help you to:

• appreciate the nature of systems design.

• appreciate the importance of co-ordinated teamwork and project management.

• apply and integrate the engineering principles taught in Part I.

• understand how to produce detailed design proposals.

• gain experience of building and testing a system once it has been designed.

• produce design and construction documentation.

• write and present reports on a design and on the resulting system.

L.3 Project Organisation

The Integrated Design Project runs in four Blocks in the first and second halves of the Michaelmasterm (Blocks M1 and M2) and the first and second halves of the Lent Term (Blocks L1 and L2). Ineach Block there are up to 15 Teams, each of six students. The Team Identifier (which is used toidentify robots and kits of components and is required on reports) comprises the Block and a twodigit Team number, e.g. M205 (for team 5 in Block M2).

The whole team is responsible for the overall systems design and for the integration of the electronic,software and mechanical sub-systems to form the complete AGV. Each team will also need toorganise itself into sub-teams responsible for the mechanical, electronics and software aspects. Thedivision of people between subteams may vary according to differing requirements at different stagesof the project.

L-01-30 5 Sept 19, 2013

Page 6: Idp Manual

L.3.1 Project Management

An important factor in the success of a team in this project and in the success of all engineeringprojects involving more than one person is effective team management. Some aspects of the projectmanagement have in effect been predetermined: the teams have six members, work areas arepreallocated and the short unalterable overall timescale imposes constraints on project timing.Other aspects are left to the teams to organise, for example:

• allocation of people to sub-teams and management of these sub-teams

• communication between sub-teams to ensure that the individual components are compatible

• detailed timetable (e.g. in the form of a Gantt Chart) to ensure that one sub-team does notdelay the others

• redeployment of manpower between sub-teams in the event of slippage in some area

• best use of manpower during integration

• team organisation during the competition

• production of coherent documentation throughout the project

When defining the project timetable it is important to list all the key tasks to be undertaken,to estimate their duration and resource requirements and to identify prerequisite and dependenttasks. Careful planning at this stage can save a great deal of time later, particularly during systemintegration.

It is clearly important for the members of the team to meet regularly throughout the project toco-ordinate the work in the sub-teams and to ensure that the overall design objectives are met. Theproject timetable should provide a useful basis for discussing progress. You are likely to find thatthe timetable has to be refined during the course of the project!

Each team is asked to select a team co-ordinator who can act as a contact for the team. In mostteams, this person will also be responsible for providing the team management, though other lessrigid structures may also be effective.

L.3.2 Work Areas

The project headquarters is in the Electrical and Information Engineering Teaching Laboratory(EIETL) and most of the project work is done there. The main exception is that, after the teamactivities concerned with the initial planning stages, the mechanical sub-teams move to the DPOand the Instrument Workshop (1st floor of the Workshops alongside the DPO) for the detailedembodiment design and construction stages of the project. Workstations are also reserved in theDPO for some sessions. The final integration and testing stages of the project, and the competitionare again team-based and in the EIETL. Even when working elsewhere, you must still attend theEIETL to sign in (see section L.5.2).

Where possible, access will be provided to these work areas outside the timetabled laboratoryperiods; but, apart from the DPO, none will be open before 08:30 or after 17:30 and availabilityshould be checked with a demonstrator beforehand in a timetabled session. You must plan on thebasis of having only limited time in any of these areas between the end of the timetabled projectsessions and the competition.

L-01-30 6 Sept 19, 2013

Page 7: Idp Manual

Subteam working LocMech Elec Soft

Thu 09:00-11:00 Lab Session L L L09:00 Introduction Lecture (LT 1)10:00 EIETL Orientation14:00 Management Lecture

FriSatSunMon 11:00-13:00 Lab Session E E E

11:30 Workshop Orientation (Teams 1-7)12:00 Workshop Orientation (Teams 8 - 14)12:15 Software Talk (SAM Meeting Room)12:15 Electronics Talk14:00 CAD Revision talk (DPO)

Tue 09:00-11:00 Lab Session E E EWed 09:00-11:00 Lab Session D E E

09:00 First Presentations14:00 CAD Revision talk (DPO)

WEEK

1

Thu 09:00-11:00 Lab Session D E EFriSatSunMon 11:00-13:00 Lab Session D E E

13:00 First Report Due13:00 Submission of Parts List

TueWed 09:00-11:00 Lab Session D/W E E

WEEK

2

Thu 09:00-11:00 Lab Session D/W E E11:00 End of 100% for DA

FriSatSunMon 11:00-13:00 Lab Session W E E

13:00 End of 85% for DA13:30 Chassis Painting Available

Tue 13:30 Chassis Painting AvailableWed 09:00-11:00 Lab Session W E E

11:00 End of 70% for DA13:30 Chassis Painting Available

WEEK

3

Thu 09:00-11:00 Lab Session W/E E E11:00 0% DA09:00 Robot/Sub-system Demo

FriSatSunMon 11:00-13:00 Lab Session E E E

11:00 Final PresentationsTueWed 09:00-11:00 Lab Session W/E E E

WEEK

4

ThuFri 09:00-12:00 Competition M2/L2 E E ESat 09:00-12:00 Competition M1/L1 E E ESunMon 17:00 Final Report Due M2/L2TueWed 17:00 Final Report Due M1/L1

Table 1: Project Timetable showing critical events. [Locations L= LT1, E=EIETL, D=DPO, W= Workshop] (See following sections re details of sessions/submissions)

L-01-30 7 Sept 19, 2013

Page 8: Idp Manual

L.3.3 Timetable

Table L.3.2 shows the complete timetable showing the approximate sequence of tasks in terms ofteam and sub-team activities is attached as an appendix to this document.

The project sessions on the coursework rota are on Monday from 11:00 to 13:00, and on Wednesdayand Thursday from 09:00 to 11:00. As with other practicals, you are expected to turn up on timefor these sessions.

Key intermediate milestones in the project are: the start of construction; and the start of systemintegration. You should aim to reach the first milestone in the middle of week 2 and the secondmilestone at the end of week 3, as suggested in the timetable referred to in L.3.3 above.

Each team will need to produce its own detailed timetable, including the action to be taken if theproposed timing for any stage of the project proves incorrect. This needs to ensure that the threesub-teams can work in parallel, i.e. that one sub-team does not have to waste time waiting fora sub-system to be delivered by another.

L.4 Deliverables / Assessed Work

The assessment is split in two with the qualifying standard for the design/build/test phases (Sectioni) being 28 marks and the reporting phase (Section ii) being 11 marks.

Section Activity Weight Marked per

i) Initial Presentation: 15% Team (individual attendance required)i) First Report: 20% Teami) Initial BoM 5%* Sub-teami) Design Acceptance: 15 % Sub-teami) Basic Functionality Demo: 9% Team/Sub-teami) Final Presentation: 15% Sub-team (individual attendance required)i) Robot Quality (sub-team): 6% Sub-teami) Robot Performance: 15% Team

ii) Final Report (Appraisal): 65% Individualii) Final Report (Documentation): 35% Sub-team

Sub-Team marks will be divided amongst team members in proportions agreed amongst the teammembers and specified in part of the Final Report Documentation. The distribution for a team ofsix is subject to the following constraints:

• the total contribution for a team member across the three topics will normally total 100%(except if the team agree otherwise). This total will also be used to apportion the team marks.

• the total contribution for all team members will total 600% (thus if one team member hasmade a less than 100% contribution, others must have made more than 100%, but this willbe capped at 125%)

• the total contribution towards a sub-team area must be between 150% and 300%

For teams of fewer than 6, the unfilled places will be treated as members making a 0% contribution(ie the total for all team members will remain 600%). For teams of more than 6, the totals will bescaled accordingly; e.g. for 7, the total available would be 700% and the total per sub-team wouldbe in the range 175% to 350%.

Demonstrators have discretion to vary this distribution of marks if it is clear that it does not fairlyreflect the contributions of some team members.

Each activity, apart from Design Acceptance and the Functionality Demos, is marked on the fol-lowing scale:

L-01-30 8 Sept 19, 2013

Page 9: Idp Manual

Mark Approximate Standard70-100% First Class (80+ exceptional)60-69% II.150-59% II.240-49% III0-39% Fail

Reports may be handwritten or word-processed. Each report will be marked by a demonstratorand returned with written feedback. Marks are awarded for the content of reports not ona per page basis and markers will deduct marks for excessive length. This applies especially tothe Final Report, see section L.4.9).

L.4.1 First Presentation - [ 15% Marks - Team ] (Individual attendance required)

An initial oral presentation is given by each team in the last session of the first week of the project,ie the Wednesday at the end of Week 1 (of Term) for M1 and L1 and of Week 5 for M2 and L2.

Each team has 10 minutes for its presentation + about 5-10 minutes discussion at the end. Eachteam member is expected to attend the presentation. A list giving the time and location of eachteam’s presentation will be posted on the IDP noticeboard in the EIETL.

The presentation is informal but should be professional. Each team should produce between 5-10printed slides, covering the topics below:-.

1 - Overall Plans, strategy and team name

2 - Mechanical design/Layout

3 - Plans for electrical Sensors/Interfaces etc

4 - Software layout/construction (inc Failure detection)

5 - Job allocation/timescales

+ - Appropriate sketches, cardboard models etc

A printed copy of which should be handed to the demonstrator at the beginning of the presentation.An electronic copy must be posted in the teams area on the bulletin board immediately after thepresentation.

You will need, as a team, to think about how the individual contributions fit together and theoverall timing, so as to ensure a professional impression. A whiteboard and/or overhead projectorwill be available for sketches and notes done at the time.

L.4.2 First Report - [ 20% Marks - Team ]

The first report is to be handed in to the demonstrators during the middle session of the secondweek of the project, ie the Monday of Week 2 for M1 and L1 and of Week 6 for M2 and L2. They willmarked and returned with comments during the next or next but one session, ie on the Wednesdayor Thursday.

The aim of the First Report is to provide written documentation of the team’s work in the initialoverall system design phase of the project. It thus covers similar work to the Initial Presentationbut should include more detailed engineering documentation rather than a narrative description.It is marked primarily on the quality of the design process followed, in particular the clarity andscope of the specifications, selection and evaluation of concepts and the overall ability of the robotto perform the task.

The report must contain:

• A coversheet specifying the team identifier, team name and robot name together with thename, lab group and College of each team member

• A solution neutral problem statement

• A requirements specification (the requirements should be quantified wherever possible)

• Sketches of the concepts you have considered (which may be photocopied/scanned from yourlab book)

L-01-30 9 Sept 19, 2013

Page 10: Idp Manual

• Evaluation charts of these concepts together with a brief discussion of the advantages anddisadvantages of each

• Specifications of the interfaces between subsystems and an outline of the framework for theirintegration (e.g. electrical signals and their relationship to the software, the position of majorelectrical and mechanical components on the chassis, the major components of the softwaresubsystem, etc.)

• An outline of project management plans, including a project timetable (e.g. in the form of aGantt chart) and details of work allocation to team members within the framework definedby the timetable

• Initial calculations, test results, the output from any software packages used as a design tool, etc. as needed to support design decisions

Sub-Team Specific requirements for the first report

Mechanical

1. Scaled orthographic Drawing(s) (or sketch(s)) of the overall robot on A3 paper showingthe:-

– Overall dimensions

– Location of major components, inc sensor positions

(Sketching/ graph/ isometric paper is available in the EIETL and DPO)

2. Discussion/calculations as a result of initial experiments with test facilities and demon-stration materials.

3. Initial BoM - see section L.4.3

Electrical

1. Results of the initial experiments (See IDP website for details)

2. List the sensors and actuator circuits required

3. Discussion of the trade off between using hardware/software

4. Initial BoM - see section L.4.3

Software

1. Results from Discussion of the significance for the design and implementation of therobot system of the results of those initial experiments (See website for details) so farconducted.

2. Discussion of

– Overall software layout, inc sub-system/subroutine communication

– Timing issues

– Recovery strategies

3. Initial BoM - see section L.4.3

L.4.3 Initial Bill of Materials - [ 5% Marks - Sub-Team ]

In the planning of a project it is useful to have a idea of the resources that will be required, to aidin costing and procurement. Due at the same time as the first report, each sub-team should submitan initial ’Bill of Materials’. If not supplied or the content is substantially different from the BoMsupplied at Design Acceptance, see section L.4.4, the mark is reduced to 0%. The individual BoMsshould contain

Mechanical - Estimation of the amount of raw material required to complete the construc-tion, list/quantities of mechanical items required, inc gears, springs, wheels etc but excludingfasteners.

Electrical - List/estimated quantities of components required to complete the sensor andcontrol circuitry, inc number of PCBs, sensors, active/passive components and connectors

L-01-30 10 Sept 19, 2013

Page 11: Idp Manual

Software - Estimate of the number of lines of code and number of source files

NB The BOMs must be supplied as separate documents and an electronic copy placedin the teams bulletin board area.

L.4.4 Design Acceptance - [ *15% Marks - Sub-Team ]

Sub-teams are required to have their detailed design checked by a demonstrator before startingconstruction. This is a relatively informal process with a pass/try again decision.

Design Acceptance takes place when a sub-team is ready; there is no fixed time for this (otherthan being during a timetabled session). A sub-team may wish to have the detailed designs fordifferent parts of its system checked at different times. This is acceptable provided that an outlinedesign for the complete system is available and is itself acceptable. It is not intended that designacceptance should be sought on a totally piecemeal basis, more than three separate elements wouldnot normally be expected. The marks will not be awarded until the complete sub-team design hasbeen accepted.

Design Acceptance completed before 11:00 on the Thursday of week 3 gains full marks; during thefollowing week the available marks drop by 15% per session until 11:00 Thursday week 4 after whichno Design Acceptance marks will be awarded. If any sub-team gets no Design Acceptancemarks, the entire team will get none. This is to emphasise the whole team’s responsibility forensuring the timeliness of this process.

*N.B. As described in section L.4.3 the mark for the initial BOM is lost if it is substantially differentfrom the BoM supplied with the DA documentation.

The purpose of Design Acceptance is to ensure that proper engineering practice is being followedand that the design is viable. The documentation must be sufficient that the sub-system couldbe constructed by a competent technician without the need to refer back to the designers. Theamount of documentation is likely to vary with the specialisation, with mechanical (by the natureof the task) requiring the most. All documentation (Drawings, Circuit diagrams, listings) shouldbe clearly identified using a label containing, at least, the information shown in the example below:

Drawing No: Title:

Team: Scale:

Drawn by: Accepted by:

Date: Date:

A design being passed should not be regarded as a guarantee of quality other than that it is adequateto prevent sub-team expending a large amount of effort constructing something which is clearlynot viable or is likely to prevent the team as a whole completing the project.

Sub-Team Specific requirements for Design Acceptance

Mechanical Design acceptance is given on the basis of the manufacturing drawings youproduce which should include:-- Overall assembly and sub-assembly drawings- Manufacturing drawings of ALL individual parts- *†Final Parts List/BoM (NB Electronic copies of the updated BOM must also be posted inthe teams area on the bulletin board system,)See the IDP website and posters in the EIETL for examples of the drawing standards required.In addition to drawing quality, the demonstrator will also consider the viability (both opera-tional and manufacturing), the safety and the adaptability (how difficult it will be to modifylater, if required) of your design before accepting it.Before you prepare these drawings, you may find it helpful to review the “Assembly Drawings”handout from your 1st year notes, and the various CAD/Creo support materials available onthe IDP website.

Electrical Design acceptance Electronics is a two stage process:-

1. Initial stage The demonstrator will:

L-01-30 11 Sept 19, 2013

Page 12: Idp Manual

– Check the circuit diagram is prepared according to the guidelines given (see examplesin EIETL and on the IDP website)

– Check the functionality of each block (without giving a guarantee that a given circuitwill work), and that it is designed with reasonable efficiency of component usage.

– Check that the power supply estimates for all functions have been completed, andthat the available power is not exceeded.

– Check for some evidence of testability, eg test points, diagnostic leds, possibility ofinjected test signals if appropriate.

– Check that attention has been paid to the interfaces with the software and mechan-ical aspects of the design.

You should be prepared to explain and justify your design to the demonstrator, as wellas show supporting calculations e.g. to determine component values.

2. Final stage The demonstrator will check

– †Wiring layout diagram

– *†Final parts list/BoM

Software Before accepting your design, the demonstrator will expect to see documentationsufficient to allow a competent team of programmers to produce a working system conformingto your design,Your documentation should include:

1. the overall function of the software system (e.g. using flowcharts);

2. its structure in terms of the interaction of the component parts (e.g. datatypes, functionsand procedures);

3. its interface to the other subsystems (e.g. pin allocation on chips);

4. example datatypes and low level procedures (e.g. those developed during the initialtesting process).

5. *†’BoM’, list of subroutines + associated size

†, electronic copies of all documents marked with a ’dagger’ should be posted on the teams bul-letin board. Any subsequent modifications to these documents should be submitted as separatedocuments.

L.4.5 Basic Functionality Demonstration - [ upto 9% Marks - Team/Sub-Team ]

Timely completion of sub-systems significantly improves the chance that the overall project will besuccessful and is a common requirement in industry. Credit can be obtained for the demonstrationof upto 3 subsystems to a demonstrator before the end of the final Monday session.

4% of the total marks are available to all the sub-teams if a combined completed chassis/Linefollowing circuit/line following program (inc a turn) is demonstrated by the end of the first (Thurs-day) session of the 4th week of the project. (The mark is reduced to 3% if the functionality is notdemonstrated until the final Monday session. If the functionality has to be demonstrated on thetest chassis only 50% of the available marks will be awarded and only to the Electrical and Softwaresub-teams)

An additional 5% of the total marks (4% if demonstrated by the end of the final Monday session)are available to sub-teams who demonstrate two individual sub-systems (i.e. 2.5% [2%] for each)e.g.:

Mechanical Completed/working mechanisms, working actuators systems

Electrical Demonstrable sensor conditioning, working actuator drive circuits, discriminationcircuits

SoftwareLine-following (inc corner/junction), Alignment for pickup, control of actuators (where ap-propriate), alignment for delivery

L-01-30 12 Sept 19, 2013

Page 13: Idp Manual

If the robot is not fully integrated, simulation by injection of signals or trial data will be accepted.Only two chances/session to demonstrate an operation will be given and the demonstrators’ decisionis final!

L.4.6 Final Presentation - [ 15% Marks - Sub-Team ]

Each team is required to make a final presentation of its work on the project in the penultimateproject session, ie the Monday of the fourth week of the project. (Week 4 of term for M1 and L1and of Week 8 for M2 and L2.) This presentation should concentrate on the detailed design workof each sub-team and the subsequent production of the robot.

The arrangements for the Final Presentation are similar to those for the Initial Presentation exceptthat each team’s session lasts 25 minutes. The presentation should last approximately 15 minutesleaving a 10 minute discussion period at the end. The presentation is done as a team but differentmarks may be awarded to each sub-team depending on the quality of their contribution.

As with the first presentation a printed copy of the 5-10 slides used should be handed to thedemonstrator at the beginning of the session. An electronic copy must also be posted in the teamsarea on the bulletin board immediately after the presentation.

The presentation should cover the following topics:

• Brief review of the overall design strategy

• Sub-team designs

• Problems encountered during implementation

• Changes to the original design and reasons for these

• Remaining problems *

• Brief statement of likely performance in the competition.

*- If a team still has technical problems after the presentation please place a posting on the ’Ask theExperts’ bulletin board before 5pm on the final Tuesday to aid scheduling during the last sessionon Wednesday.

L.4.7 Competition - [ 15% Marks - Team ]

The competition for blocks M1 and L1 takes place on the Saturday morning and for M2 and L2 onthe Friday morning following the end of the project.

Each member of a team whose robot successfully performs the task set will receive a First Class mark(typically 75%, higher for the best robot or robots). Performance marks will be reduced for teamswhose robots are not completely successful in completing the task, require manual intervention orincur penalties during the competition. Teams whose robots fail to attempt the task will normallyreceive Fail standard marks for Performance.

Following the competition, photographs will be taken of the robot and put on the IDP Web site,whence they can be downloaded for inclusion in the Final Report.

L.4.8 Robot Quality - [ 6% Marks - Sub-Team ]

Quality will be assessed and marks allocated by the demonstrators following the competition at theend of each block. Team quality will focus on the overall concept and its embodiment.

Mechanical

– Quality of construction

– Appropriate simplicity

– Robustness

– Ease of assemble/disassemble to accommodate repairs and modifications

Electrical

L-01-30 13 Sept 19, 2013

Page 14: Idp Manual

– Neat, logical component layout.

– Good use of wire colour-coding, routing and test points in order to aid diagnostics andcircuit de-bugging.

– Quality of soldering and other circuit construction techniques such as correct use of ICsockets and other connectors.

Software [N.B. A complete printed copy of the listing must be supplied at the end of thecompetition]

– readability and maintainability of the program

– smoothness and speed of movement especially when line following

– provision for error recovery

NB The Assessment will take into account if the team has made use of the loan of any pre-builtparts, e.g. Line Following boards, during the design and construction phase of the robot.

L.4.9 Final Report [ 65% Marks - Individual, 35% Marks - Team ]

The final report comprises two elements: an individual assessment of the project as a whole; anda team report consisting of a compilation of design and implementation documentation producedduring the project. Both reports are to be submitted on the Wednesday after the project ends forblocks M1 and L1, and on the Monday after the project ends for blocks M2 and L2. The reportswill be marked and returned at the beginning of the following term.

L.4.9.1 Engineering Assessment of the Project - [ 65% Marks - Individual ]

The assessment must be written individually and a signed statement is required to confirm this (seebelow). You may refer to factual material, drawings etc, contained in the team report. Where theseare essential to a reader of this report, copies should be included as an appendix. A photograph ofthe robot should be included.

The report should be a critical technical assessment of the work done and the outcome achieved,including

1. team management aspects of the project – not a narrative describing how you did the workon a day to day basis.

2. Major decisions made during the project should be reviewed and comment made on theircorrectness.

3. discussion should be put in the context of the robot’s performance in the competition andthat of other different designs.

4. Short discussion (1 paragraph) on the cost of producing the prototype and possible savingsfor a production run of 100 - 1000 units. (See the inside of the back cover for a personal timesheet and the IDP website for a spreadsheet to help analyse costs)

Your report must include on the cover:

• your name, lab group and college;

• your team identifier;

• total word count for the report excluding appendices; and

• a signed statement declaring the report to be all your own work. (Any shared materialshould be included in appendices to the report with references to it in the main text.)

The length of the report should be equivalent to approximately 5 to 6 sides of A4 typescript,including diagrams but excluding appendices. The report must not either exceed 6 sides or exceed2,400 words.

L-01-30 14 Sept 19, 2013

Page 15: Idp Manual

L.4.9.2 Project Documentation - [ 35% Marks - Team ]

The Project Documentation should primarily be a compilation of design and implementation doc-umentation and should comprise the following:

• Coversheet (using template on project Web site).

• Table of contents.

• Photograph of the robot (Available from the IDP website following the competition) .

• Sub-team sections containing

– Documentation submitted for Design Acceptance

– Any changes to the above should be noted and explained.

– The material should be divided into sections and indexed so that the reader can findparticular items as easily as possible

• Final Gantt Chart (or similar).

• Completed project cost spreadsheet

• Appendix 1: The First Report.

N.B. Project handouts should be used as reference material and not be reproduced in the reports.

L.5 Additional Logistics Information and Equipment Provided

L.5.1 The 1B Robot Desktop Environment

The desktop environment for the project is accessed via the green arrow icon at the bottom of theTeaching System screen and then clicking on the 1BRobot icon. This environment has desktop iconssimilar to those for the 1A and 1B Programming Classes plus Pro/Engineer, project managementsoftware and a link to the IDP Web site.

If you need help remembering how to use this environment, the online help available via the CUED

Help icon and thence via the Introduction to the Teaching System and C++ links may be useful.

A special shared group file space is set up for each team for the project. Within this there are folders(or directories) for each team member (named with their login identifier) and a Common folder:

• Each team member can read and write files in their own folder and the Common folder; andread files in one another’s folders.

• There is an icon on their desktop for a team member’s own shared folder as well as the usualicon for their private home folder (for unshared files). Double clicking on this shared folderlaunches the file browser providing access to the folder and to the others in the shared groupfilespace.

• There is a link created in each team member’s private home folder named idp shared pointingto the team’s shared folder. This is useful for accessing this folder from programs like aterminal window which start up in the home folder.

L.5.2 Penalties for Lateness

You must ensure that you are signed in by a demonstrator in the EIETL at the start ofevery timetabled project session. You are required by the Department’s Coursework Committeerules to attend these sessions punctually, ie arriving by 09:05; lateness by up to 10 minutes, ie09:15, will carry a penalty of one coursework mark; any later than this the penalty will be twocoursework marks.

In general work submitted late will not be accepted. The one exception is the Final Reportfor which one mark will be deducted for every day late that it is submitted, up to aweek ( 5 working days) ; work will not be accepted more than a week late.

If you are penalised for late arrival or late handing-in of work due to circumstances beyond yourcontrol, you should apply for the recovery of the marks via your College Tutor or Director of Studies

L-01-30 15 Sept 19, 2013

Page 16: Idp Manual

using the standard Allowance procedure administered by the Department’s Teaching Office.

L.5.3 Laboratory Notebook

You will be issued with a Laboratory Notebook. This is to be used: to record day-to-day activities;to record details communicated to other sub-teams, eg interface specifications; as a sketch book forconceptual design work; and to record calculations relating to the design steps.

The notebook will not be handed in for marking, but demonstrators may check that there is adequatesupporting material for things described in the reports and that it has been used correctly withentries properly laid out and dated.

L.5.4 Inventory and House Keeping

At the end of the project you are expected to

1. Clean and clear your teams area in the Workshop2. Clean and clear your teams area in the EIETL3. *Complete a inventory checklist of the major kit items and tools supplied to you during the

project.

*There will be a charge made if any items are missing. You will be required to supply a chequemade payable to University of Cambridge attached to the inventory form to cover the cost ofthe missing item(s).

L.5.5 Reports

The 1A Exposition Course document A Guide to Report Writing by J D Lewins and J A Williamssets out some guidelines for undergraduate reports on experimental and project work. You shouldreread this document before writing your reports.

Diagrams and other graphical material form an important part of any report (a picture is worth athousand words).

L.6 Suggestions and Feedback

Suggestions for improvements in the organisation and structure of this project, and for future prob-lem specifications which might be set for later projects, will be very welcome. The Fast Feedbackmechanism should be used for this purpose. Please also complete the section of the on-linesurvey relating to the IDP as soon as you have finished the project.

L-01-30 16 Sept 19, 2013

Page 17: Idp Manual

1B Integrated Design ProjectMobile Robot – Systems Design

D.1 Introduction

This section describes the system design process for the mobile robot. It is the responsibility ofthe whole team to clarify the task, produce an overall specification and undertake the conceptualdesign of the robot. Having produced an overall specification and chosen an appropriate concept,the subteams should then be able to specify, design and build subsystems that can be integratedinto the final design.

D.2 Design Process

The various activities and resulting outputs of the design process are shown in Figure 1 below.Within a relatively simple multidisciplinary project such as the IDP, it is usual for the whole designteam to be responsible for the design process up to and including concept selection and thereafterfor each subteam to concentrate on their particular specialisation.

Useful general guidelines for the design process are given in the following paragraphs – refer to thePart IA handout “An Introduction to the Design Process” for more detail.

The initial task in any design process is to derive a solution-neutral problem statement, i.e. astatement which identifies the real problem to be solved whilst avoiding any indication as to how itis to be solved. Having decided on the problem statement, it is then necessary to clarify the designtask by identifying the true requirements and constraints. The result of this phase is a detailed listof design specifications – a requirements specification.

The next phase is conceptual design, where concepts with the potential of fulfilling the requirementslisted in the design specification must be generated. The overall functional and physical relationshipsmust be considered and combined with preliminary embodiment features. Sketches of the conceptsshould be produced.

Subsequently, an evaluation of the different concepts must be performed. The evaluation is based onthe wishes identified in the design specifications. More than simple yes/no answers are required todetermine the relative merits of each concept. An evaluation chart, where each criterion is weightedto indicate its relative importance for each concept, should be produced.

Where a design is to be the responsibility of more than one person, and, in particular, when thedesign task is multidisciplinary, as in the IDP, it is important for each team member and subteamto be clear which aspects of the design are their responsibility and to agree the interfaces of theirdesign with the other team members and subteams. Having decided an overall specification andconcept as a team and agreed the interfaces of their design with the other subteams, it should thenbe possible for each subteam to proceed with their particular design process.

Although the model shown in Figure 1 implies a sequential process, in practice design is very rarelyso. For example, it is often necessary to amend the product specification – perhaps as a result ofchanges requested by the market or as a result of additional information gleaned as part of thedesign activity itself.

D.3 Overview of Tasks

The main design tasks on the IDP are the vehicle structure (its motion and its object han-dling/transportation functions), the electronics interface and the software control program. Each ofthese are subject to constraints which will need to be identified and incorporated into the design.

D-01-6 17 October 04, 2010

Page 18: Idp Manual

ACTIVITIES RESULTS

Market need (in this case the IDP problem statement)

Identify real need

Identify requirements

Elaborate specification

Solution-Neutral Problem Statement

Requirements

Specification

Conceptual Design

Embodiment Design

Detail Design

Concept

Layout

Manufacturing Instructions

Subteam responsibility

Team responsibility

Figure 1: The Design Process

These include general constraints, such as the recyclability of the robot, as well as specific ones,such as the limited materials and components.

In particular, the following issues should be considered in the first stages of the robot design:

• The overall strategy, including the software control strategy

• The choice of wheel base (the layout, number of wheels, front or rear wheel drive)

• The choice of drive system, gear boxes and wheel sizes (the effects of these on traction, vehiclespeed, stability etc.)

• The design of the object handling system (the adequacy of lifting forces, its reliability andeffectiveness, its interaction with the drive system)

• The electronics interface between the microprocessor and the ‘real world’. The use of sensors(which of the available sensors fulfil the required functions best?)

• The positioning and mounting of sensors (see the IDP website for more information)

• The overall manufacture of the design (the appropriate construction sequence and timetable,

D-01-6 18 October 04, 2010

Page 19: Idp Manual

anticipated difficulties etc.)

• Energy management of the system

• Risk evaluation. Consider carefully your proposed strategy and design – what are the greatestrisks to a successful outcome and what measures can you take to minimise these?

These decisions will have implications for the whole team. Thus, on-going consultation with yourteam members is essential.

D.4 Characterisation Tests

There are a number of experimental rigs available in the project laboratories. These are mostlyspecialised test facilities which are described in the relevant subteam documents. In the EIETLab there are rudimentary robots and a pneumatics test rig which may be useful to the team as awhole in characterising the motors, pneumatics and associated equipment. Ask demonstrators forguidance on using these experimental rigs.

D-01-6 19 October 04, 2010

Page 20: Idp Manual

1B Integrated Design ProjectMobile Robot – Mechanical Design

M.1 Introduction

This section describes the mechanical design and construction of the mobile robot. The aim of themechanical subteam is to design and build the robot’s chassis and object handling system and, inconjunction with the other subteams, test the robot which will be controlled via on-board electronicsand software routines.

The kit of parts provided includes motors, pneumatic actuators and structural materials. Fasteners,lubricants, adhesives and other components, such as springs and gears, are also available.

Useful guidelines for prototype design and manufacturing are given in the handout ‘Practical guide-lines for mechanical design and manufacturing’, copies of which can be found in the DPO and EIETLab and on the IDP website.

M.2 Design Process and Overview of Tasks

As part of the overall system design undertaken by the whole team, you should have clarified thetask, produced an overall specification and selected a design concept. The next phase of the designprocess is the embodiment design of the mechanical aspects of the robot, where the foundations arelaid for detail design through a structured development of the concept. The result of this phase is adetailed layout drawing, showing the preliminary shapes of all the components, their arrangementand, where appropriate, their relative motions.

Finally, in the detail design phase, the precise shape and dimensions of every component have tobe specified, and the material selections made or confirmed. You are then in a position to startmanufacturing. Manufacturing drawings (with an accompanying parts list) should be produced forevery component to be manufactured. Individual drawings must be accepted (and the accompanyingassembly drawing at least checked) by a demonstrator before construction of that component canbe commenced in the workshops.

The main mechanical design tasks are the vehicle structure, the detailed drive system and itsobject handling/transportation functions. Each of these are subject to constraints which will needto be identified and incorporated into the design. These include general constraints, such as therecyclability of the robot, as well as specific ones, such as the limited materials and components.Your decisions will have implications for your team members working on the software and electronicsdesign. Thus, on-going consultation with your team members is essential.

M.2.1 Vehicle Structure

The vehicle must conform with the requirements of the problem statement. The vehicle must carrythe electronics and the micro-controller unit and, if pneumatic actuators are used, the vehicle mustalso carry a spool valve assembly (providing the link between the compressed gas line and theactuators). The attachment of the micro-controller unit to the vehicle should be made using thebracket provided. Note that the attachment of the umbilicals to the vehicle must be secure andshould be positioned so as to cause least inconvenience to the vehicle when in motion.

M.2.2 Motors and Pneumatic Actuators

The specifications and characteristics of the motors and pneumatic actuators are included on theIDP website. Note that compressed gas can only be used in connection with the spool valves to runthe actuators. A test rig is available in the EIET Lab for testing your pneumatic actuator assemblyseparately.

M-01-20 20 Sep 30, 2010

Page 21: Idp Manual

It is a requirement of the design that all main assemblies provided (including the motors andactuators) be re-usable on completion of the project. No permanent modification of the componentsis permitted (e.g. gluing of the wheels onto the motor shaft). The motors may not be modified.Wheel-motor clamps are provided in the kit of parts.

You will need to work in conjunction with the software subteam in order to determine experimentallyappropriate embodiment details of the drive system.

To design the actuator system for object handling, you may find it useful to refer to the ‘Practicalguidelines for mechanical design and manufacturing’ handout for some examples of linkages, pivotsand spring arrangements. This is available in the DPO and the EIET Lab and on the IDP website.

M.3 Robot Manufacturing

Although the design of the vehicle and object handling mechanism should be considered as a whole,it may be advantageous to build the basic vehicle (chassis and motor/wheel arrangement) before theobject handler in order that the software and electronics members of your team may start testingthe control of the vehicle.

It is important to note that the parts in the kit will not be replaced unless found to be defective.Cardboard is available for model testing. In addition, parts such as springs and gears are availableon request but they are of limited supply.

Structural materials as listed in the mechanical kit list may be obtained from Mr Christmas in theworkshop. Materials request forms for this purpose are available in the workshop. Note that thereare fixed limits as to the quantity of each material available.

Guidelines on manufacturing techniques can be found in the handout entitled “Practical guidelinesfor mechanical design and manufacturing” (which is available in the DPO and the EIET Lab andon the IDP website).

M.3.1 Workshop Safety

When using the workshop, you must follow important safety procedures:

THE WORKSHOP IS AN EYE PROTECTION AREA. PLEASE WEAR YOUR SAFETY GOG-GLES WHEN OPERATING MACHINERY.

Before operating any machine please ensure:

1. You are not wearing loose clothing2. Long hair is tied back3. The workpiece is securely clamped4. If in doubt, check with the workshop staff before commencing work

Note: Compressed gas is potentially dangerous; please use the airline and pneumaticcontrol lines with care.

M-01-20 21 Sep 30, 2010

Page 22: Idp Manual

1B Integrated Design ProjectMobile Robot - Electronics Design

E.1 Introduction

E.1.1 General

This section describes the electronic part of the Mobile Robot Project. The aim of the electronicssub-team is to design, build and test the interface electronics for a mobile robot. The resultingelectronic circuits will be the interface between the robot’s transducers, which provide informationon the ’real world’, and the robot’s on-board microprocessor.

A kit of parts is supplied, containing two circuit boards on which your circuit is to be built. One isa pre-configured board for a line following circuit with a limited amount of prototyping space, thesecond is a prototyping board. The use of two boards allows flexibility in the construction of theelectronics and testing of the robot. (A further prototype board is available if the space is requiredand can be justified to a demonstrator). You will also have a range of electronic componentsavailable from simple resistors and compacitors through to CMOS logic, operational amplifiers anda programmable logic module. The transducers that can be used include infra-red/magnetic/strainsensors and micro-switches. Electronic interfaces are also required for any actuators.

The sequence of the design process for the interface electronic circuits is outlined in this document.Detail on the prototyping boards, individual assemblies and components and their usage is givenon the IDP website. Full data on the ICs and transducers and the actuator circuit is provided inthe Electronic Component Data section of the website and may be found on the internet.

The marking of the project will take into account the approach to the design process and the qualityof the final circuit. Assessment will be based on the clarity of the circuit specification and diagrams,the reliability and layout of the complete circuit and its ability to perform the task specified. Thisis an integrated design project, and careful co- operation is required between those dealing with theelectronic, software and mechanical aspects of the design.

E.1.2 System Overview

The completed prototyping boards are connected to a microcontroller module (see the IDP website)via a standard communication bus known as I2C (Inter-Integrated-Circuit bus. The module alsoincludes a wireless interface (802.11b) enabling communication between the microcontroller and aworkstation or terminal on the Engineering Department’s teaching network.

Electrical power comes from a 12v bench power. The supply to the microcontroller and otherelectronics is regulated to 5V, ±15v in the microcontroller unit. The module and prototyping boardsare connected via 9 way D plugs/sockets which carry the I2C bus, +5V, ±15v + unregulated +12vand a ground line; the current in this 5V supply line to the prototyping boards should be designnot exceed 0.4A.

When the vehicle is operating in its working area the 12V power line can be supplied via anumbilical, which also supplies the pneumatic supply.

There are power drivers for two(/four) drive motors in the microcontroller. The motor terminalsshould be linked directly to the connectors on a drop cable supplied with the microcontroller module.

Pneumatic Actuators, which may be used to power the pick and place mechanisms, are poweredby the pneumatic supply. The pneumatic valves are controlled using electrical signals from theprototyping board or the prototyping area on the ’line sensing’ board.

E.2 Design Process

The interface electronics circuit design process can be split into stages:

• Definition of circuit functions.

E-01-31 22 Sep 29, 2010

Page 23: Idp Manual

• Circuit embodiment design and calculation of resistor and capacitor values.

• Circuit documentation.

• Circuit construction and test.

• System integration.

All the information you should need on the I2C bus and the transducers is provided in the Appen-dices and the Data Book. The ICs and components listed in the Data Book form part of the basickit for the project.

The operation of the interface electronic circuits can be considered under the following headings:

• Line following using infra-red emitter/detector assemblies: The robot’s path in the work-ing area is defined by white lines on the black surface. The infra-red sensors provide theinformation on the robot’s position relative to the line.

• Obstacle and target detection using microswitches or infra-red emitter/detector assemblies:Microswitches can be used to detect contact between the robot and an obstacle or target.The infra-red assemblies can be used to detect the presence of a reflecting obstacle withoutcontact.

• Detection/Identification - for example, route selection by detecting signals from transmittersor load sorting by use of sensors.

• Control of ’pick and place’ mechanism.

• Light emitting diode indicators to show sensor or actuator status.

E.3 Design Tasks

E.3.1 Defining Circuit Function

The circuit function must be defined as a team activity. The circuit function follows from thevehicle specification required to carry out the problem specified as the task for your robot.

Figure 2 shows the main functional blocks of a complete interface circuit. The only part of thiscircuit which is already defined is the link to the I2C bus, which must be through the PFC85748-bit input/output port ICs. The 8574 port addresses are defined by links on the prototyping andline sensor boards and must correspond to the addresses used in the software.

The first task of the electronics sub-team is to define the type and number of sensors and actuatorsthat you will need to perform the functions that your robot requires. You can then define the signalprocessing sub-circuits. Your complete circuit should:

• control the infra-red emitting diodes and ensure reliable detection of the infra-red signals forhigh and low levels of reflection and with the possibility of cross-talk between adjacent sensors,

• ensure reliable detection of microswitch operation in the presence of contact bounce,

• detect any parameter (eg IR beacon, load material) that defines the task to be performed,

• Ensure the current supplied to the ’pick and place’ driver is adequate.

There may be some advantages in combining the states of two or more sensors using logic gatesrather than using software. The hardware/software trade-off should be discussed during the initialdesign stage.

E.3.2 Circuit Embodiment Design

As shown in Fig. 1, the sub-circuits link the sensors and actuators to the 8574s and via the I2Cbus to the microcontroller.

Define the operation of each sub-circuit in terms of its function, using logic statements and timingdiagrams if necessary. Note carefully whether a given sequential logic component is level- or edge-triggered and which trigger polarity is being used. Use your notebook to record this informationand any calculations that you make.

Then devise a circuit which implements the functions. Some guidance on the form the circuit may

E-01-31 23 Sep 29, 2010

Page 24: Idp Manual

Figure 2: Block diagram of sensor interface circuits

take is given in the Appendix to this document. You should include LED indicators to show thestatus of certain sensors or actuators. These indicators can help considerably when you are testingthe complete vehicle. Using the information and tables provided in the Electronics Data Bookproduce a complete circuit diagram, showing which gates you are using within each IC package.Calculate and record the values required for resistors and capacitors.

Prepare a table showing any significant current requirements (say greater than 10 mA) of individualdevices. Estimate the expected 5V supply current required by your board under worst case load.

E.3.3 Design Documentation

E.3.3.1 Circuit Diagrams

Circuit diagrams should be prepared according to the following guidelines:

• Standard symbols should be used.

• All interconnections should be clearly indicated, both within and between circuit blocks, andincluding power supply connections.

• Interconnections should be shown as an interconnecting line, or by allocating a unique labelto a signal and then labelling ”hanging” interconnections, or by a sub-table of connections(eg as may be used to list power supply connections).

• Unused devices within ICs (eg unused gates) should be shown, with inputs defined high orlow as necessary.

• Unconnected pins on ICs should be included, and labelled NC (no connection).

• If power supply distribution lines are shown, the most positive should appear towards the topof the page, and the most negative towards the bottom.

Where a single IC has several gates or other functions, ensure that only one set of power lines isshown for that particular IC. Pin numbering is essential and will be of assistance when constructingthe connection diagram and circuit. Demonstrators can asdvise on ideas as to how to draw this ina clear manner (there is no standard approach).

E.3.3.2 Parts Lists and Connection Diagrams

A parts list and a connection diagram showing the components and their orientation where ap-propriate (eg LEDs, ICs, diodes, MOSFETs etc) and the wiring needed in your circuit should be

E-01-31 24 Sep 29, 2010

Page 25: Idp Manual

prepared.

Use a consistent scheme for the orientation of the IC carriers. Plan the layout of the IC packagesto reduce the length of interconnections as far as possible. The circuit should be easy to check, testand modify. Ensure that your indicating LEDs will be visible when the circuit board is mountedon your vehicle. An A4 copy of the prototyping board is available to help plan the layout.

If your documentation is complete, then a competent technician will be able to build the circuitexactly to the stated requirements. Complete documentation is also required when assistance isbeing sought.

Your final report (see L.4.9) must contain the overall circuit diagram, component connection dia-gram and parts list and each must appear on a single sheet of A4.

Ask a demonstrator if you are uncertain about any stage of the design.

E.3.4 Printed circuit boards (PCBs)

See Week 1 Tasks and Exercises document

E.3.5 Circuit Construction

Design acceptance is needed before starting circuit construction - see section L.4.4.

Circuits can be developed on either of the boards supplied, i.e.

1. The line sensor board which is split into two sections a pre-configured area for a standardoptical sensor circuit and a small prototyping area, see IDP Technical Databook.[NB Pre-built versions of the board are available for ’hire’, prior to manufacture. However,(a) teams must have demonstrated a working LED drive circuit on breadboard, (b) The usewill be taken into account during the assessment of the robot quality and (c) an additional’consultancy’ charge will be levied for inclusion in the overall cost sheet.]

2. The prototyping board is also split into two distinct areas, the prototyping area and an areadedicated to the I2C bus interface circuits, see IDP Technical Databook.

The prototyping areas are arranged in 2 columns (1 column on line sensing board). Two continuoustracks for the +5V and 0V lines run in the centre of each column. A standard dual-in-line IC can bemounted so that each pin is linked to two connecting holes. Connections between pins and discretecomponents are to be made with suitable gauge wire and soldered joints. Within the dedicated areaa socket for an 8574 IC is required to be mounted on the board; the port address may be selectedusing jumper connectors.

The I2C bus and power for the board is supplied via a D plug mounted on one end of the boards.(N.B. These connections are continued through tracks on the board to the socket at the other endenabling more than one board to be used.

The infra-red and actuator assemblies will be provided with leads attached; you will be required towire the appropriate connectors on to the board, together with the via pins and the D plugs/socketssupplied with each board.

Use IC carriers both to avoid damage to the circuits during the soldering and so that the circuitscan be re-used.

Wire the circuit in stages, taking each function in turn. Use single-core wire for the board andmulti-core for the connections to external components. You may find it helpful to use different wirecolours for each function. Then test the function and return to wire the next stage.

E.3.6 Circuit testing

When you have completed a stage of wiring, check with the multi-meter that the power suppliesare routed to the correct pins on the IC holders and sensor connectors before inserting the ICs andsensors. Always switch off the power before inserting or removing an IC or a sensor.

E-01-31 25 Sep 29, 2010

Page 26: Idp Manual

Take each functional block in turn and establish that the function is correct. Generate suitable testprocedures without using the microcontroller initially, bearing in mind that the 8574 output pinswill be either logic 1 or logic 0. Use the oscilloscope to check any timing sequences based on a clockoutput. If you find your circuit is not working correctly, devise a methodical approach to find thefault. Ensure first that the power and ground are properly connected. Then systematically tracesignals through the circuit from their point of origin.

Ensure the design of the infra-red sensor circuits can cope with small variations in the ’black’ and’white’ reflected light levels: changes in mounting height, marks on the white tape and scuffs onthe black table surface can cause problems if your design is not tolerant. If a pneumatic systemis used, confirm that the actuator driver will operate the control valve solenoid and measure thesolenoid current.

E.3.7 System Integration and Testing

When you are satisfied that the circuit works to its design specification, try to link it to themicrocontroller. The software sub-team should have written test procedures which will allow youto confirm that the required functions are all operating correctly before the complete mechanicalassembly is available. N.B. The team is supplied with a sample chassis which can be use to test thesystem.

The final tests of your circuit must be designed and carried out as part of the functional tests ofthe complete vehicle assembly.

E-01-31 26 Sep 29, 2010

Page 27: Idp Manual

IB Integrated Design Project

Mobile Robot - Software Design

S.1 Introduction

This section describes the software part of the Mobile Robot Project. The software provides theoverall control for the robot and, in this project, can either run in general purpose workstations ofthe type used for other programming activities in the course or be downloaded into the on-boardmicroprocessor. The former environment facilitates software development and is hence commonlyused in the development phase of projects which have complex software components. The latter ismore suitable for late prototype and, of course, production versions of the system.

As in the other tasks in the project, a kit of parts is provided. In this case, the kit consists of a set(a software library) of datatypes and functions which can be used by a C++ program to control therobot. The core of this library is a datatype (robot_link). There are different implementationsof this for the two environments. For programs running in the workstation, the library controlsthe sending of three byte command messages from the workstation over a wireless network tothe microprocessor in the robot (see the IDP Technical Databook for further details). Thismicroprocessor interprets these instructions, produces signals to control the hardware and sendsback three byte response messages to the software in the workstation. For programs running inthe microprocessor, communication with the hardware is direct. This communications mechanismis fully provided by the software library and the details, including whether messages are sent overthe network or not, are unimportant to the programmer (one of the benefits of having softwarecomponents). The IDP Technical Databook contains, for background information, some of theadditional details of the implementation of the library.

A number of initial experiments are outlined which provide useful design data, familiarity with theprogramming environment and the library, and which calibrate some of the robot functions neededlater in the project. Following this, the software development merges with the rest of the projectand the aim becomes that of solving the overall robot design problem described in the ProblemStatement.

Guidance is given on Software Engineering techniques, some additional features of the C++ pro-gramming language, and on aspects of report writing specific to the software part of the project.This guidance only suggests a general framework, there is a great deal of scope for individualcreativity!

S.2 Methodology for Producing Software Systems

In the last thirty years, a new branch of Engineering, Software Engineering, has grown up. This,like other branches of Engineering, has a set of methodologies for designing and building (or im-plementing) systems. As in other branches of Engineering, one of the central ideas is that ofdecomposing a large difficult problem into a set of simpler sub-problems, these sub-problems maythen be further decomposed into yet smaller sub-problems until a level of complexity is reachedat which the solution becomes relatively trivial. The sub-problem solutions are the components ofthe complete solution and can be assembled to form a solution to the overall problem. Some ofthese components may pre-exist or may be useful at a later stage as parts of some other system;for example, components of the programs written during the initial experiments in this project arelikely to be reusable as low level components in the final control program.

In the context of Software Engineering, the components are program elements like subroutines andfunctions. Associated with these are the datatypes and data objects on which they operate. Somemethodologies (functional) place the principal emphasis on the program elements, others (object

S-01-30 27 Sept 17, 2013

Page 28: Idp Manual

oriented techniques) on the data. Often the former approach is most suitable for the top levels (i.e.first levels of decomposition); whereas for the lower levels it may be easier to think in terms of thedata first, then what operations are required on it and then to contain both within an abstractdatatype (e.g. a C++ class - see the IDP Technical Databook). For this project, the low-level components which are provided are C++ classes but the code to be written can follow eithermethodology.

Another important design issue is ensuring that the software components fit together. This typicallyinvolves specifying what data each requires as input and what output it produces. The clearestspecifications arise when the input is in the form of parameters to a procedure or function and theoutput (if any) is the value returned by a function. C++ classes may be useful for grouping relateddata and operations, and for limiting the number of separate objects which need passing around.Global data (see the IDP Technical Databook) should be used with care.

The production of a software system can be split into a number of phases –The Software Lifecycle:

Requirements Definition – define what the system is required to do.

System Design – design the overall system structure.

Component Design – design the individual components.

Implementation – write the software which implements the component design.

Integration – fit the components together and to other non-software parts of the system.

Testing – making sure it works reliably (including its reponse to unusual or erroneousinputs).

These phases generally overlap and may not be entirely sequential, eg: component testing beforeintegration; and iteration back from a later phase to an earlier one. Some iteration of this kind isexpected but large loops back (e.g. testing revealing mistakes in the requirements definition) areclearly to be avoided if at all possible! Throughout the process, there is a further very importantactivity: the production of documentation.

Proper application of these techniques should result in software that is written and documented insuch a way that it can subsequently be maintained and developed, not necessarily by the originalauthors. Bearing this in mind should help you to decide how successful you are being in producinggood software.

When designing software, you should also bear in mind other engineering techniques which youhave learnt. For example, the sequence of actions performed by the robot could be modelled as astate machine (IA Digital Electronics course) and the software could then be designed around thismodel.

S-01-30 28 Sept 17, 2013

Page 29: Idp Manual

S.3 Introduction to the use of the Software Library

The software library contains off-the-shelf components to control the robot and to provide somesupport functions. The facilities provided by the library, based around the class robot_link, arediscussed in detail in the IDP Technical Databook. These describe the complete set of routinesavailable (not all are required for the project; for example the instructions to control the ultrasonicsensors are only needed if these are being used).

In addition, the IDP Technical Databook provides an introduction to some aspects of the C++language (like bit manipulation and using classes) which are not covered in the IA ComputingPracticals but which are likely to be useful for this project.

S.3.1 A Simple Example Program

The following program shows simple use of the robot software library and illustrates some of itsessential elements. Note the use of the dot operator (‘.’) to access the robot_linkmember functionsin the same way as accessing structure data (The IDP Technical Databook describes this in fullerdetail).

#include <iostream>

using namespace std;

#include <robot_instr.h>

#include <robot_link.h>

#define ROBOT_NUM 33 // The id number (see below)

robot_link rlink; // datatype for the robot link

int main ()

int val; // data from microprocessor

if (!rlink.initialise (ROBOT_NUM)) // setup the link

cout << "Cannot initialise link" << endl;

rlink.print_errs(" ");

return -1;

val = rlink.request (TEST_INSTRUCTION); // send test instruction

if (val == TEST_INSTRUCTION_RESULT) // check result

cout << "Test passed" << endl;

return 0; // all OK, finish

else if (val == REQUEST_ERROR)

cout << "Fatal errors on link:" << endl;

rlink.print_errs();

else

cout << "Test failed (bad value returned)" << endl;

return -1; // error, finish

In this program, the header files defining the robot instruction set (robot_instr.h) and the softwareinterface for the link (robot_link.h) are included.

The program initialises the link, sends a test instruction and checks that this returns the correcttest result from the robot. This program could thus be run on a workstation to verify that thelink and the microprocessor in the robot are operating correctly. The ID ROBOT_NUM is the numberon the network interface card plugged into your microprocessor. This will normally correspond to

S-01-30 29 Sept 17, 2013

Page 30: Idp Manual

your group number within the block, e.g. for group M206 it would be 6. A version of this programto be downloaded and run on the microprocessor would not need ROBOT_NUM information since itcommunicates with the local hardware (see the IDP Technical Databook).

S.3.2 The Workstation Programming Environment

For programs to be run on the workstation, this part of the project mainly uses those facilitiesfamiliar from the Part I Computing Practicals, e.g. the IDPgeany program for compiling pro-grams. Programs written during the project can be compiled using the facilities provided by the1BRobotgeany desktop environment which is accessed via the ”Applications” icon at the bottomof the Teaching System screen and then clicking on the 1BRobotgeany option in the ”All CUEDApplications/2nd year” section. This environment has desktop icons similar to those for the 1Aand 1B Programming Classes plus, project management software and a link to the IDP Web site.

If you need help remembering how to use this environment, the online help, the Introduction to theTeaching System and C++ links may be useful.

A special shared group file space is set up for each team for the project. Within this there arefolders (or directories) for each team member (named with their login identifier) and a Commonfolder:

• Each team member can read and write files in their own folder and the Common folder; andread files in one anothers folders.

• There is an icon on their desktop for a team members own shared folder as well as the usualicon for their private home folder (for unshared files). Double clicking on this shared folderlaunches the file browser providing access to the folder and to the others in the shared groupfilespace.

• There is a link created in each team members private home folder named idp shared pointingto the teams shared folder. This is useful for accessing this folder from programs like aterminal window which start up in the home folder.

S.3.2.1 Geany

Just drop the source files all at the same time onto the icon and click on Make. Alternatively, dropa folder onto the icon (in which case all the *.cc, *.C, and *.cpp files in the folder will be used).Here are some frequently asked questions

1. When I use the geany icon, the compiler complains about the robot commands - make sureyou’re using the IDPgeany icon, not the geany icon left over from the 1st year. The IDP iconsappear when you start a session using the 1BRobotgeany option

2. When I use the geany IDP icon, Build doesn’t work - you need to use Make in the Buildmenu: clicking on the Brick icon isn’t enough.

3. What files do I drop into the compiler icon? - all the files that comprise the project exceptfiles that you have #included. You need to drop them in all at the same time. Alternatively,drop a folder onto the icon, but make sure the folder only contains project-related source files

4. I’ve created a file in geany, but I can’t compile it - Quit from geany, then drop the sourcefile(s) into geany

5. I’ve been developing code on windows. Now I’ve copied it onto the CUED machines it doesn’tcompile - use dos2unix to convert the file’s line-endings.

6. I have several independent source files in geany. Flicking between them amd using Makedoesn’t work. - This version of geany (unlike the 1A Mich version) assumes that the filesinitially dropped onto it form a single program. Close geany and load just one of your files in.

7. The Execute (”gearwheel”) button does nothing - this can happen if you’re running a programthat’s in a folder you’re not allowed to create files in.

S-01-30 30 Sept 17, 2013

Page 31: Idp Manual

S.3.2.2 Other IDEs

Several other Integrated Development Environments are available on the system. Note that

• Compiling needs CCSWITCHES=”-I/export/teach/1BRobot” and LIBS=”-L/export/teach/1BRobot”

• Cross-compiling needs CCSWITCHES=”-I/usr/arm-unknown-linux-gnueabi/include -I/export/teach/1BRoband LIBS=”-L/usr/arm-unknown-linux-gnueabi/lib”. The compiler is arm-linux-gnueabi-g++

S.3.3 The Microprocessor Programming Environment

In addition to running programs on the workstation, it is also possible to cross-compile them anddownload them to run on the microcontroller directly. The processor in the microcontroller doesnot use the same machine code instructions as the workstation. It uses an Intel XScale PXA270processor that incorporates an ARM microprocessor core. Code compiled to run on a workstationwill not run on the microcontroller, instead you must use an ARM cross-compiler.

S.3.3.1 Cross-compiling, Downloading and Running Programs

The following very simple example shows how to cross-compile and run a program on the micro-controller. Suppose the program is in a file hello.cc containing

#include <iostream>

using namespace std;

int main()

cout << "Hello World" << endl;

To cross compile and link the above program, drag the hello.cc file to the IDPgeany-arm icon (ratherthan the normal IDPgeany icon) on the desktop, and click on the Make button. This will producean executable file named hello.arm (.arm distinguishes it from the executable hello which IDPgeanywould produce to run on the workstation). Next

• Copy the file to the robot. To do this you need to use the unix command line to run a programcalled scp (SecureCoPy). Use the Terminal icon in the task ba

to give you a Unix Terminal window with a command line.

• A short Unix crib is online, telling you about 3 useful unix commands: ls (to list files), pwd(to see which directory (aka folder) you’re in) and cd (to change directory). It’s useful to goto the directory (aka folder) where your program is. You can do this by typing

cd directory-name

but there’s a short cut. Using the File Viewer, display the folder where hello.arm is (e.g.abc12/IDP-Shared/abc12/python2 folder). In the Terminal window, type cd followed by aspace, then with the mouse drag the folder’s name (in this case python2) into the Terminalwindow.

cd ’/users/s/abc12/IDP-Shared/abc12/IDP/python2’

Press the Enter key to change directory.

• Now use the scp command from the Terminal window, replacing 100 in the example below bythe number on the WiFi card.

scp hello.arm [email protected]:hello.arm

– scp is the program you’re running. It’s not in the current folder (it’s a system command)so you don’t need an initial ./

– hello.arm - the name of the file you’re copying over.

S-01-30 31 Sept 17, 2013

Page 32: Idp Manual

– team - the name of the user on the robot. It’s always team

– wlan-robot100.private - the name of the robot you’re using. Don’t use 100. Use thenumber on the WiFi card.

– hello.arm - the name the file will have on the robot. It needn’t be the same as the originalfile-name

scp might print messages about authenticity. Don’t worry - just say yes. It will then promptfor the team’s password: enter the password printed on the side of the microcontroller box.When you type the password nothing appears on screen.

• Run the program. First log into the robot, replacing 100 in the example below by the numberon the WiFi card.

ssh [email protected]

After typing the password correctly you’ll be logged into the robot and you’ll be given a Unixprompt . You can type ls to list the files on the robot. You should see hello.arm there. Torun it, type

./hello.arm

(the ’.’ means the ’current folder’ - by default, the system doesn’t look in the current folderfor programs, so you need to make it look there)

You can either logout from the microcontroller at this point to return to work on the workstation or,perhaps more conveniently, leave this terminal window logged-in to the microcontroller and openanother on the workstation to do subsequent program development, compilation and downloads.

S.3.3.2 Cross-compiling robot control programs

This follows much the same method as above. In the same way that IDPgeany does for theworkstation, IDPgeany-arm knows about the appropriate header files and libraries for programsto be run on the microcontroller and can handle multiple source files as well as just one. Theonly difference in use between IDPgeany-arm and IDPgeany is that the output executable from theformer is name.arm (and will only run on the ARM chip) whereas for the latter it is just name.Apart from using IDPgeany-arm rather than IDPgeany, the only other change normally required isto the initialisation of the robot link object (see later for details). When running on the workstation,the network interface card number is required; when running on the microcontroller, none shouldbe specified to indicate that communication is local.

This can most easily be achieved by using conditional compilation (see the IDP Technical Data-book) and using whether or not arm is defined to distinguish between the two compilers andhence select the correct version. Thus for the program in S.S.3.1 above, the rlink.initialise lineis replaced by

#ifdef __arm__

if (!rlink.initialise ()) // setup for local hardware

#else

if (!rlink.initialise (ROBOT_NUM)) // setup the link

#endif

S.4 Tasks to be performed

S.4.1 Formulating the Software Requirements

You should start to define the functionality of your software at an early stage both to ensure thatthe software you write can meet the evolving system specification and so that you can start toproduce components of it (eg procedures and suitable datatypes) as soon as possible. Bear in mindwhen designing and writing your software that the design of other parts of the system may haveto change due to unforseen problems and that the software should be easily adaptable to thesechanges.

S-01-30 32 Sept 17, 2013

Page 33: Idp Manual

One aspect of the design which will need early thought is the line following algorithm since this willdepend on such factors as response time and sensor placement.

S.4.2 Initial Tasks and Experiments

See the Week 1 Tasks and Exercises document

S.4.3 Other Tasks

Alongside these tasks, the other sub-teams will be producing their subsystems and may need youto produce test programs to help to test these out. For example at some point you will be able toreplace the test chassis by the proper one. You should discuss these requirements as a team.

Towards the end of the above tasks, you should be in a position to start the Software Lifecycle forthe complete final program which will control the robot when it is performing the task describedin the Problem Statement. See the Design Acceptance section ( L.4.4) for guidance on what thedesign and implementation documentation should contain and the earlier discussion (S.2) of softwareengineering and the Software Lifecycle.

Testing should take place alongside the mechanical and electrical systems as each is refined toproduce the final working robot. Initially this testing is likely to comprise component testing ofparticular software modules, e.g. line following, against specific electrical and mechanical subsys-tems before the final complete system testing is undertaken. It is important to aim to ensure thatany problems are discovered as early as possible in the development process.

S-01-30 33 Sept 17, 2013

Page 34: Idp Manual

K.5 Introduction

- See also on the IDP website for more details and datasheets.

K.5.1 Mechanical Materials/Components

Transmission components Per kit

Wheels, soft rubber tyre, 100 dia 2 4 availableWheels, soft rubber tyre, 75 dia 2Castors, soft rubber tyre, 50 dia 2Either Large motor/gearbox 12v DC, 20rpm &40rpm

Initially 1 of each Three motors max,two of any one speed.

or Small motor/gearbox 12v DC, 18rpm & 40rpm Initially 1 of eachWheel/motor connector kit 2 pairs

Pneumatic components

Pneumatic actuator (inc nut and clevis) 10 bore ×45 stroke

2

Swivel connector (mounted on actuator) 4Pneumatic valve assembly 1

Structural materials (available in the workshop) Per team

Mild steel sheet, 22swg (450×450 max) 1 Note: swg to mm con-versions

Aluminium sheet, 1.5mm (200×150 max) 1 (swg = standard wiregauge)

Aluminium tube, 19 dia, 1mm wall, 150 long 1 24swg = 0.6mmAluminium rod, 8 dia, 150 long 1 22swg = 0.7mmAluminium angle, 12.5×12.5×1.6 (600 max) 1 21swg = 0.8mmMild steel tube (5/16 od × 21swg) 300 long 1 18swg = 1.2mmMild steel tube (3/8 od × 22swg ) 300 long 1 16swg = 1.6mmPolypropylene sheet 300×150×1.5 1Mild steel rod 4 dia 300 long,Mild steel rod 6 dia 300 long,Brass rod 6 dia 100 long,Brass hex 6 AF 100 long,

Pneumatic materials

Pneumatic hose, 1500mm max (from EIET Lab) 1Pneumatic ‘T’ connector (if required) from MikeBrown

2

K-02-24 34 September 30, 2012

Page 35: Idp Manual

Fasteners and other materials (available in the workshop)

M2.5/M3/M4/M5/M6 nuts & washersM2.5 × 12 Socket head Cap Screws (motormounts)M3 × 10, 16, 20 Socket Head Cap ScrewsM4 × 10, 16, 20, 25 Socket Head Cap ScrewsM5 × 16, 20, 25 Socket Head Cap ScrewsM6 × 16, 25, 40 Socket Head Cap ScrewsM3/M4/M6 studdingPop rivetsAdhesive-backed foam stripAdhesivesLubricants

There is a limited range of springs, spur and bevel gears, gear racks and bearings available – seethe IDP website or see the demonstration board in EIETL. Structural materials, springs, spur andbevel gears, gear racks and bearings must be booked out using a materials request form from MrChristmas. Fasteners, lubricants are available in the workshop. Adhesives are available in theEIETL, please only use in one the sheets provided.

K.5.2 Electrical Components

Standard Team KitNo. /team No. /team

Line Following 1 Prototyping PCB 1Infra red detector amplifier as-sembly

1 Infra red emitter/detector as-sembly

4

Thermistor assembly & ther-mocouple materials*

1 Infra red Sensor test board 1

5v power supply lead (proto-typing use only)

1 Motor/gearbox to PCB headerlead

1

Microcontroller to PCB 12vlead

1 Breadboard + starter kit 1

Note that components will be issued by the Project demonstrators. Other than the com-ponents listed above, no reasonable limit is placed on the numbers of each component youmay use. A record will be kept of materials used by each team and demonstrators may wishto check your circuit before issuing components.

Available ’Electronic’ Components

Microswitch Integrated circuit socketsPCB headers and Connectors:(2, 3 &5 way)

Crimp terminal

Push button switch, SPST,PCB mounting

Relay, 12v DPCO, PCBmounting

Resistors:

CFR carbon film 0.25 W 5%Available in decade ranges of 100 to 105 in the following values: 10, 12, 15, 18, 22, 27, 33,39, 47, 56, 68 and 82 (up to a maximum of 106 ohms)

K-02-24 35 September 30, 2012

Page 36: Idp Manual

PCB mounted Potentiometers:

10 KΩ &500Ω multiturn 10, 22 & 200Ω single turn

Capacitors:

10nF 50v multilayer ceramic 0.1µF 50v multilayer ceramic0.22µF 50v multilayer ceramic 0.47µF 50v multilayer ceramic1µF 50v multilayer ceramic 0.1µF 35v tantalum (long lead positive)0.22µF 35v tantalum (long lead positive) 4.7µF 16v tantalum (long lead positive)10 µF 16v tantalum (long lead positive) 22 µF 16v tantalum (long lead positive)47 µF 16v tantalum (long lead positive) 470 µF 16v Electrolytic

Range of 74C series IC’s :

74HC00 Quad 2 i/p NAND gate 74HC08 Quad 2 i/p AND gate74HC14 HEX Scmitt-trigger inverter 74HC74 Dual D-type flip flop74HC85 4-bit comparator 74HC112 Dual J-K flip-flop74HC123 Dual retriggerable monostable 74HC273 8-bit D-type flip flop74HC393 Dual 4-bit binary counter

Other active devicesMC33172P Dual OP Amp ICM555 TimerLM311 Comparator ZVN4306A Enhancement MOSFET driverPCF8574 8 bit expander for I2C-Bus 3mm LED Red3mm LED Green Diode 1N4001Diode bridge W005 7805 5v RegulatorL293 Push/Pull 4 channel driver LTC 1152 ’Zero drift’ op amp*SFH 313FA Phototransistor* GP2Y0A21YK Distance sensor*SS495A Hall Effect Sensor* Strain Gauges Strain gauges mounted on

beam5mm LED White IDPPic 12F675 Pic module

* if required by the task set

Note: A handout giving general information on HCMOS logic and data sheets on relevant devicesis available from the IDP website.

K.5.3 Software Components

Software Library 1Microcontroller module 1Power supply unit plus output lead 1Al Chassis kit 1Sensor simulation pcb + I2C cable 1

K-02-24 36 September 30, 2012

Page 37: Idp Manual

Team :- . CRSid :- .

Mechanical Electrical Software Admin

Design

Constru

ction

Testing

Docs

Design

Constru

ction

Testing

Docs

Design

Constru

ction

Testing

Docs

Meetings.

Coord

ination

Pre

senta

tions

/hrs /hrs /hrs /hrs /hrs /hrs /hrs /hrs /hrs /hrs /hrs /hrs /hrs /hrs /hrs

Week1

Thurs.Fri.Satur.Sun.Mon.Tues.Wed.Total

Week2

Thurs.Fri.Satur.Sun.Mon.Tues.Wed.Total

Week3

Thurs.Fri.Satur.Sun.Mon.Tues.Wed.Total

Week4

Thurs.Fri.Satur.Sun.Mon.Tues.Wed.Total

Week5

Thurs.Fri.Satur.Sun.Mon.Tues.Wed.Total