Ongo01: Project OSCAR

Spring 2005 Project PlanClient:

Iowa State University,Department of Electrical and Computer Engineering

Faculty Advisor: Prof. Ralph E. Patterson III

Team Members:

Kevin Cantu EE 491Philip Derr EE 491Jawad Haider EE 491David Hawley Cpr E 492Zachary Kotlarek Cpr E 492Michael Larson EE 492Jeff Parent CprE 491Justin Rasmussen Cpr E 492Gavin Ripley Cpr E 492Peter Rufino EE 492Jason Sytsma EE 492

Report Disclaimer Notice:DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This 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. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This 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 this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator.

11 Feb 2005

Ongo-01: Team OSCAR

Table of ContentsList of Figures..................................................................................................................................vList of Tables..................................................................................................................................viList of Tables..................................................................................................................................viList of Symbols..............................................................................................................................viiList of Symbols..............................................................................................................................viiList of Definitions........................................................................................................................viii1 Introductory Materials.............................................................................................................1

1.1 Abstract............................................................................................................................11.2 Problem Statement...........................................................................................................1

1.2.1 General Problem Statement.....................................................................................11.2.2 General Solution Approach.....................................................................................2

1.3 Operating Environment...................................................................................................21.4 Intended Users and Intended Uses...................................................................................2

1.4.1 Intended Users.........................................................................................................21.4.2 Intended Uses...........................................................................................................3

1.5 Assumptions and Limitations..........................................................................................31.5.1 Assumptions............................................................................................................31.5.2 Limitations...............................................................................................................3

1.6 Expected End Product and Other Deliverables...............................................................42 Proposed Approach and Statement of Work...........................................................................5

2.1 Functional Requirements.................................................................................................52.1.1 Easy-to-use software package shall control the robot wirelessly............................52.1.2 Speech control via on-board microphone................................................................52.1.3 Autonomous navigation down a hallway................................................................52.1.4 Object manipulation via end effector......................................................................52.1.5 Rechargeable power source.....................................................................................52.1.6 Easy demonstration capability.................................................................................5

2.2 Constraint Considerations................................................................................................52.2.1 Computer System.....................................................................................................6

2.2.1.1 Memory................................................................................................................62.2.1.2 Size......................................................................................................................62.2.1.3 Maximum Power Load........................................................................................62.2.1.4 Wireless...............................................................................................................62.2.1.5 Motherboard slot availability...............................................................................6

2.2.2 Electromechanical System.......................................................................................62.2.2.1 Minimum power availability...............................................................................62.2.2.2 Minimum battery charge......................................................................................72.2.2.3 Battery size constraints........................................................................................72.2.2.4 Maximum power load on battery.........................................................................72.2.2.5 End effector constraints.......................................................................................8

2.3 Technology Considerations...........................................................................................112.3.1 Computer System...................................................................................................112.3.2 Speech Recognition...............................................................................................112.3.3 Wireless Connection..............................................................................................112.3.4 Power Usage..........................................................................................................11

i

Ongo-01: Team OSCAR

2.3.5 End Effector...........................................................................................................122.4 Technical Approach Considerations..............................................................................12

2.4.1 General Considerations..........................................................................................122.4.1.1 Team sizes.........................................................................................................122.4.1.2 Decisions............................................................................................................13

2.4.2 Design and Implementation Approach..................................................................132.5 Testing Requirement Considerations ............................................................................14

2.5.1 New software testing.............................................................................................142.5.2 Speech recognition testing.....................................................................................152.5.3 Automated software testing...................................................................................152.5.4 Signal output of wheel tachometer circuit.............................................................152.5.5 Computer power supply.........................................................................................15

2.6 Security Considerations.................................................................................................162.6.1 Project Development.............................................................................................162.6.2 End-Product Operation..........................................................................................16

2.7 Safety Considerations....................................................................................................172.8 Intellectual Property Considerations..............................................................................172.9 Commercialization Considerations................................................................................172.10 Possible Risks and Risk Management...........................................................................17

2.10.1 High-Level Risks...................................................................................................172.10.1.1 Equipment failure..........................................................................................172.10.1.2 Failure to complete assigned tasks................................................................18

2.10.2 Medium-Level Risks.............................................................................................182.10.2.1 Unauthorized spoken commands...................................................................182.10.2.2 Ordered parts do not arrive on time...............................................................182.10.2.3 Cost of development exceeds expectations...................................................182.10.2.4 Machining tragedy.........................................................................................18

2.10.3 Low-Level Risks....................................................................................................192.10.3.1 Software testing shows bugs in code.............................................................192.10.3.2 Failure to attend a meeting............................................................................19

2.11 Proposed Milestones and Evaluation Criteria................................................................192.11.1 Project Milestones.................................................................................................19

2.11.1.1 Technology selection.....................................................................................192.11.1.2 End product design........................................................................................192.11.1.3 End product implementation..........................................................................192.11.1.4 End product testing........................................................................................192.11.1.5 End product documentation...........................................................................192.11.1.6 Project reporting............................................................................................202.11.1.7 End product demonstration............................................................................20

2.11.2 Evaluation Criteria.................................................................................................202.12 Project Tracking Procedures..........................................................................................21

2.12.1 Project reporting....................................................................................................212.12.2 Internal project tracking.........................................................................................21

2.13 Statement of Work.........................................................................................................212.13.1 Technology selection.............................................................................................21

2.13.1.1 Select speech recognition software................................................................22

ii

Ongo-01: Team OSCAR

2.13.1.2 Select I/O interface for end effector..............................................................222.13.1.3 Consider end effector control solutions.........................................................222.13.1.4 Consider end effector hardware solutions.....................................................232.13.1.5 Consider purchase of DC/AC inverter...........................................................23

2.13.2 End-product design................................................................................................242.13.2.1 Design wheel tachometer circuit...................................................................242.13.2.2 Design software to interact with wheel tachometers.....................................242.13.2.3 Develop navigation algorithm.......................................................................252.13.2.4 Design end effector controller.......................................................................25

2.13.3 End product implementation..................................................................................262.13.3.1 Implement speech recognition.......................................................................262.13.3.2 Revise existing GUI software........................................................................262.13.3.3 Implement wheel tachometer circuit.............................................................272.13.3.4 Implement software to interact with wheel tachometers...............................272.13.3.5 Install wheel tachometers..............................................................................272.13.3.6 Repair SONAR array.....................................................................................282.13.3.7 Implement new end effector..........................................................................28

2.13.4 End-Product Testing..............................................................................................292.13.4.1 Characterize SONAR array...........................................................................292.13.4.2 Test newly developed software.....................................................................292.13.4.3 Automate software testing.............................................................................302.13.4.4 Test new end effector.....................................................................................30

2.13.5 End-Product Documentation.................................................................................302.13.5.1 Document wheel tachometer circuit..............................................................302.13.5.2 Document newly developed software............................................................312.13.5.3 Document end effector controller..................................................................31

2.13.6 End-Product Demonstration..................................................................................312.13.6.1 Present robot to campus visitors....................................................................312.13.6.2 Develop scripts and macros...........................................................................32

2.13.7 Project reporting....................................................................................................323 Estimated Resources and Schedules......................................................................................33

3.1 Resources.......................................................................................................................333.1.1 Personnel effort requirements................................................................................343.1.2 Financial requirements...........................................................................................353.1.3 Project schedule.....................................................................................................36

4 Closing Materials...................................................................................................................374.1.1 Client information..................................................................................................374.1.2 Faculty advisor information...................................................................................374.1.3 Student team information......................................................................................37

4.2 Closing Summary..........................................................................................................404.3 Appendices......................................................................................................................A

4.3.1 Modular end product design...................................................................................A4.3.2 Milestone priority assignment method....................................................................B4.3.3 Risk Assessment method........................................................................................G4.3.4 Progress chart example...........................................................................................H4.3.5 Specifications for potential control solutions.........................................................A

iii

Ongo-01: Team OSCAR

4.3.6 Optima D34/78 battery specifications.....................................................................E4.3.7 D-Link DWL-122 Specifications............................................................................G4.3.8 Code Specifications................................................................................................H

4.3.8.1 Comm..................................................................................................................H4.3.8.2 Command............................................................................................................L4.3.8.3 Motion.................................................................................................................N4.3.8.4 MotionCommand.................................................................................................P4.3.8.5 MotionReader......................................................................................................R4.3.8.6 Network...............................................................................................................T4.3.8.7 Sensors...............................................................................................................W4.3.8.8 Serial...................................................................................................................X4.3.8.9 Speech..............................................................................................................AA4.3.8.10 OscarGUI......................................................................................................CC

4.3.9 Software interface diagram..................................................................................DD4.3.10 Screenshots...........................................................................................................EE

4.3.10.1 GUI Screenshots...........................................................................................EE4.3.10.2 Main Window...............................................................................................EE4.3.10.3 Drop-down menus........................................................................................GG

iv

Ongo-01: Team OSCAR

List of FiguresFigure 2.1 : Cycle length of Optima D34/78 battery 7Figure 2.2 : Components and measurement convention on end effector assembly 8Figure 2.3 : Technical approach flow chart 14Figure 2.4 : Locked façade and opened access door 16Figure 3.1 : Overall project schedule 36Figure 4.1 : Modular design of end product AFigure 4.2 : Example project tracking chart HFigure 4.3 : NMOS H-Bridge Circuit Design Schematic AFigure 4.4 : PMOS/NMOS H-Bridge Circuit Design Schematic BFigure 4.5 : Specification for LM629 chip CFigure 4.6 : Specification for LT1158 chip DFigure 4.7 : Software interface diagram DDFigure 4.8 : Normal mode layout EEFigure 4.9 : Advanced mode layout FFFigure 4.10 : File menu GGFigure 4.11 : Script menu GGFigure 4.12 : View menu GG

v

Ongo-01: Team OSCAR

List of TablesTable 2.1 : End effector motion.......................................................................................................9Table 2.2 : Physical dimensions of the end effector........................................................................9Table 2.3 : Weight of components in gripper................................................................................10Table 2.4 : Weight of components in forearm...............................................................................10Table 2.5 : Weight of components in wrist....................................................................................10Table 2.6 : Weight of components in upper arm...........................................................................10Table 2.7 : Weight of components in base....................................................................................10Table 2.8 : Total weight of assembled components......................................................................10Table 2.9 : Milestone Prioritization...............................................................................................20Table 3.1 : Task description reference chart..................................................................................33Table 3.2 : Estimated personnel requirement 1.............................................................................34Table 3.3 : Estimated personnel requirement 2 (continuation)......................................................34Table 3.4 : Estimated project costs................................................................................................35Table 4.1 : Priority grid for sensor system tasks.............................................................................CTable 4.2 : Priority grid for software system tasks.........................................................................CTable 4.3 : Priority grid for electromechanical system tasks..........................................................DTable 4.4 : Priority grid for general tasks.......................................................................................DTable 4.5 : Priority weight assignments by color code...................................................................ETable 4.6 : Project priority assignment chart for tasks....................................................................ETable 4.7 : Project priority assignment chart for milestones...........................................................FTable 4.8 : Risk level assignment chart..........................................................................................GTable 4.9 : Risk assignments by color code....................................................................................GTable 4.10 : D-Link DWL-122 Specifications...............................................................................G

vi

Ongo-01: Team OSCAR

List of Symbolso Degrees

® Trademark restriction applies

§ Section reference

Summation of terms

vii

Ongo-01: Team OSCAR

List of DefinitionsAC Alternating current

Azimuth Horizontal direction expressed as the angular distance between the direction of a fixed point (as the observer's heading) and the direction of the object

Ball and roller bearings Cup and race constructing bearings with rollers or balls between cup and race

CAD Computer-aided design software

Composite bushing A self-lubricating linear bearing lined with plastic

COSMOSWorks Finite element analysis software by the SolidWorks Corporation

CPU Central processing unit

CVS Concurrent Versions System

DC Direct current

DC/DC converter A device that is placed between an electrical power source and its load. The unit changes the source voltage to a useable level for the load.

Deep-cycle A type of rechargeable battery that can be almost completely drained before it must be recharged.

Drive train The assembly of electrically controlled motion elements, including the robot’s wheels, gears, belts, and tachometers

EBay® http://www.ebay.com, an auction website

End effector The assembly of electrically controlled mechanical arm and gripper

Ethernet A widely used computer network communication protocol

GUI Graphical user interface

Iglide® A bushing produced by the igus® corporation

Javadoc® A code commenting system designed by Sun Microsystems®

Kevlar® A polymer made by DuPont®

Linear bearing A rolling element that moves on a straight track

Radio Ethernet A method of utilizing the Ethernet protocol over radio frequencies

RAM Random-access memory

RPM Revolutions per minute. The number of complete rotations of the wheel in one minute.

Runout Movement from side to side

SAE Society of Automotive Engineers

viii

Ongo-01: Team OSCAR

Serial radio link A method of sending sequential information between networked computers over radio frequencies

Servo gearmotor Electric motor used to control components

Solidworks® A CAD program developed by the Solidworks Corporation

SONAR Sound navigation and ranging

Super Grip® Rubber coating made by the Plastech® Company

Tachometer A device for indicating speed of rotation from the wheels

Troubleshoot Assess and amend problems that arise during the engineering process

Wrought material Pre-machined stock material

ix

Ongo-01: Team OSCAR

1 Introductory MaterialsThe following sections serve as an introduction to Project OSCAR, its current status, and overall goals.

1.1 AbstractThe purpose of Project OSCAR is to generate an interest in people of all ages about the possibilities in the field of engineering and technology. By using interactive software and technology to control a robot the team hopes to fascinate young minds, intrigue incoming students, and impress all who behold it.

Several accomplishments were made last semester, including the implementation of a GUI software package with speech output, design of an end effector, and wireless capability. This semester’s objective is to achieve speech control, implement a functional end effector, and design a control mechanism for it.

An operational robot will be able to move and perform demonstrations without assistance. By the end of next semester, the Department of Electrical and Computer Engineering will have an enormous achievement that can be shown to the community with pride. This will help to instill an appreciation for engineering and create a desire to work in the field of electrical engineering.

1.2 Problem StatementContinuing problems with the robot’s functionality remain unsolved. It is currently immobile, has a dysfunctional end effector, and is running an incomplete software suite with few comments explaining the code’s function. This section describes the general problems faced, and the approach which will be used to solve them.

1.2.1 General Problem StatementThe overall task is to develop a fully-functional robot that the university can use for demonstrations. To be a success, the robot needs the several components to work together. One of the most relevant components is power: the battery must be able to supply enough power to operate the wheel motors, onboard computer, sensory array, and end effector. The wheel motors and tachometers must communicate with the computer so that a user can choose the robot’s speed and direction. Similarly, the sensor array needs to be able to communicate with the computer so that data concerning the robot’s surroundings can be interpreted. The robot needs an end effector so that it can manipulate objects in its surroundings. The onboard computer must control and listen to all these components. Each main component – the power and drive train, onboard computer, sensory array, and end effector – must fit inside its own layer on the existing robot chassis. An easy-to-use software package must be developed so that an average person will be capable of operating the robot. As well as manual control, speech control also needs to be implemented as an alternate method for operating the robot. The software must communicate with the robot wirelessly so that no cables need to be attached.

1

Ongo-01: Team OSCAR

1.2.2 General Solution ApproachTo ensure that the robot is receiving enough power, the total required voltage will be determined in advance so that the appropriate battery will be installed. All wiring should be done cleanly and labeled appropriately. Interface panels will be installed so that replacing fuses and recharging the battery can be done without the need for a complete understanding of how the power system works. To move the robot, a motor controller will be chosen that can interface with wheel tachometers as well as the onboard computer. Wheel tachometers will send data to the motor controller so individual wheel rotational speed can be monitored. The sensor array will need a microcontroller capable of receiving commands and relaying data back to the computer. Once this is done, the sensor array can be characterized in a test environment to determine the accuracy of the compass and each transducer in the array. A retractable end effector will be designed and manufactured with simplicity and versatility in mind. A motor controller capable of interacting with computer must be designed for this component as well. To assist the average computer user, a GUI will be developed for robot control. The keyboard and simple interface buttons will be used to move the robot, move the end effector, and to speak text. To implement speech control, appropriate speech recognition software must be researched and installed to interact with the existing software.

1.3 Operating Environment

The end product shall operate in controlled environments: primarily indoors with temperature, humidity, and air quality that are closely related to human living conditions. The components may be exposed to some outdoor environments, but only in favorable weather conditions and for a limited amount of time. Most demonstrations of the robot’s capabilities will be performed in a typical classroom setting, or under ideal (sunny, warm) outdoor weather conditions. Acceptable temperatures range between 14o and 33o Celsius and the humidity level may vary between 0% and 90%.

The robot has been designed to operate on a flat surface such as a smooth floor. There must not be any drop-offs or stairs that lead downward in the area. If obstacles are present, they must be at least 2.5 feet high for the SONAR to detect them.

1.4 Intended Users and Intended UsesThe robot will primarily be used in a learning environment for demonstration purposes. A more detailed analysis of intended users and uses is discussed below.

1.4.1 Intended UsersAny educated person will be able to control the robot manually or through spoken commands. That person must be capable of reading and understanding the output screen of the control software. A team member must be present to take control of the robot in the event of an emergency.

2

Ongo-01: Team OSCAR

1.4.2 Intended UsesMembers of the team will give interactive demonstrations of the robot’s capabilities to grade school and high school students to raise interest in engineering programs at Iowa State. The end product’s demonstrable capabilities include:

Autonomous navigation of a hallway Ability to pick up and place objects via the end effector Ability to speak Manual movement via wireless control software Control via spoken commands

1.5 Assumptions and LimitationsWhen developing the robot, certain factors must be assumed to be true or false before implementation can begin. Similarly, there are certain limitations that must also be taken into consideration.

1.5.1 AssumptionsThe following assumptions have been made when making planning or operational decisions:

Any operator of the end product must be proficient with the English language. Prior to operating, any operator of the end product shall be informed how to use the

control software. Trained team members will be present when the robot is being operated. To control the robot during presentations, the operator shall have a wireless USB adapter

and a Windows PC with the control software installed. The battery has been fully charged before demonstrations. The battery shall only be used to supply power to the motion control components,

onboard computer, speakers, sensory array, and end effector. The current drive train control unit is fully functional. The existing computer hardware is fully functional to handle existing computing loads. The sensory microcontroller shall relay accurate data to the onboard computer. Laboratory space is available on campus for fabrication of the end effector. All components purchased will operate within their specified limitations.

1.5.2 LimitationsThe following limitations will be taken into consideration:

The robot must be minimally operational at all times so that the robot can be demonstrated on schedule presentation dates.

To maintain a wireless connection, the robot can be no more than 328 feet away from the computer controlling it (see §4.3.7: D-Link DWL-122 Specifications).

Under a full battery charge, the robot can not currently remain in operation for more than one hour.

Spoken commands are executed from no more than 20 feet away. Recognized speech patterns shall not exceed twenty commands to limit processor load. All systems must reside within in the robot’s chassis. The width of the chassis is fixed at 30 inches.

3

Ongo-01: Team OSCAR

1.6 Expected End Product and Other DeliverablesThe expected end product will consist of everything needed for a client to take advantage of all the robot’s capabilities (see §2.1: Functional Requirements). The following components will be included with the end product:

The robot unit with lockable, removable façade A GUI-driven software package with the following features:

o Wireless connection to the roboto Manual motion control based on desired speed and directiono Speech outputo Autonomous hallway navigationo End effector controlo Speech recognition to relay commandso Script recording and playback to run several commands in a defined order

Robot instructions manual Operating software instructions manual Power system wiring documentation and schematics Motion controller documentation Sensory microcontroller documentation and schematics End effector controller documentation and schematics

4

Ongo-01: Team OSCAR

2 Proposed Approach and Statement of WorkThe following sections detail the proposed approach to the anticipated work this semester.

2.1 Functional RequirementsThis section details some of the functional requirements of the robot.

2.1.1 Easy-to-use software package shall control the robot wirelesslyThe robot will be capable of being controlled manually from a remote location up to 328 feet away by using a wireless network connection. The software will remain in a graphical format to make operation much simpler, especially for users unfamiliar with the robot. The software shall control aspects of the robot such as speech output, four-directional movement, movement speed, and end effector motion.

2.1.2 Speech control via on-board microphoneThe robot shall be capable of operating via spoken commands from desired users. A microphone that can sufficiently amplify these commands and send them to the software will be installed. A set list of commands will be generated that will include move forward, move backward, turn, stop, and speak. Manual control will be capable of overriding spoken commands if necessary.

2.1.3 Autonomous navigation down a hallwayThe robot shall be capable of autonomous navigation down a standard-size hallway of a commercial building. It will use its SONAR array to detect surroundings and adjust its motion accordingly. The robot will be able to be stopped manually at any time during navigation.

2.1.4 Object manipulation via end effectorThe robot shall be capable of extending and retracting its end effector in order to reach and manipulate objects. It can carry small objects while moving and operate simple mechanical objects with gripping and twisting motions. End effector control shall be achieved through the GUI software package.

2.1.5 Rechargeable power sourceThe robot’s batteries shall be rechargeable via wall outlet, using a standard American 60Hz, 120 VRMS signal. Reporting panels shall display power load and availability. The batteries and fuses shall be replaceable when necessary.

2.1.6 Easy demonstration capabilityThe unit must be charged, and the presenter must have the software package installed on a PC with a wireless connection. With these prerequisites, the robot can be easily presented to campus visitors and prospective students.

2.2 Constraint ConsiderationsThe following sections detail the constraint considerations placed upon the robot.

5

Ongo-01: Team OSCAR

2.2.1 Computer SystemThe follow constraints relate to the computer system.

2.2.1.1 MemoryThe software system shall run both the operating system and the runtime environment in no more than 192 MB of RAM.

2.2.1.2 SizeThe computer system must fit in the computer module, which is an octagon of inner radius 12 inches depth 10.5 inches.

2.2.1.3 Maximum Power LoadThe load on the power system by the computer system shall not exceed 250W, as specified by the DC/AC inverter.

2.2.1.4 WirelessAll software created to use the robot’s wireless capability shall function on a wireless connection of no more than 11 megabits per second. The wireless control subsystem shall function at a range of zero to 328 feet (see §4.3.7: D-Link DWL-122 Specifications).

2.2.1.5 Motherboard slot availabilityThe computer system motherboard must have at least one ISA slot to support the existing motion control card.

2.2.2 Electromechanical SystemThe following constraints relate to the existing electromechanical system.

2.2.2.1 Minimum power availabilityThe robot draws current from a sealed Optima D34/78 battery. It is a 6-cell, deep-cycle battery with a 12Vdc nominal output. Operation time is limited to 120 minutes when drawing a load of 25 Amperes. The battery’s cycle length is illustrated in Figure 2.1. This figure was provided without supporting data by the customer support staff at Optima. An official specification sheet is provided in §4.3.6: Optima D34/78 battery specifications.

6

Ongo-01: Team OSCAR

Optima Group 34 Deep CycleDischarge Time vs. Discharge Rate @ Room Temperature to 10.5V

Log-Log plot

10

100

1000

10000

1 10 100

Discharge Rate, Amps

Disch

arge

Tim

e, m

inut

es

Figure 2.1 : Cycle length of Optima D34/78 battery

2.2.2.2 Minimum battery chargeBecause of the quality of the battery it can be operated to full depletion before being recharged, however after each use the battery will be charged fully.

2.2.2.3 Battery size constraints The power system must fit in the bottom octagonal shaped module with an internal radius

of 12 inches and a depth of 10.5 inches. The drive train assembly and all associated control circuitry must fit in the center portion of the bottom module in an area 17 inches deep by 10 inches wide.

All external user interfaces must be built in an area limited by the surface area of the sides of each module. The external surfaces of the bottom module are 10 inches by 10.5 inches, and those of the top module are 10 inches by 6.5 inches.

The end effector unit and all associated drive/control mechanisms must fit inside the top module, which is an octagon with an internal radius of 12 inches and a depth of 6.5 inches.

2.2.2.4 Maximum power load on battery The drive train assembly shall be powered by a 12-volt DC input. The load on the power

system by the drive train shall not exceed 28 Amperes.

7

Ongo-01: Team OSCAR

The arm and gripper assembly shall be powered by a 12-volt DC input. It shall not draw more than 18 amperes during operation.

2.2.2.5 End effector constraintsFigure 2.2 illustrates motion constraints for the end effector by using the directional convention shown. Constraints for individual components are listed below.

Figure 2.2 : Components and measurement convention on end effector assembly

The current design is composed of the following degrees of freedom:Pivoting shoulder joint range of motion

Rotates through a range of 180° in the X-Y plane, centered at the X-axis satisfying the design criteria of 120°.

Rotate from 0° to 180° in the X-Y plane in a 3-second time span.Retracting shoulder joint range of motion

Fully retracts into the chassis to ease movement and navigation when not in use. Moves from zero extension to full extension in a 4-second time span.

Pivoting elbow joint range of motion Has a pivoting range around the X-axis from -90° to 90° Pivots from -90° to 90° in a 4-second time span.

8

Ongo-01: Team OSCAR

Rotating wrist joint range of motion Rotates 90° about the axis defined by the forearm, originating about the X-Z plane Rotates from 0° to 90° in a 3-second time span.

Opening/Closing gripper range of motion and weight capacity Manipulates objects up to 3.5 inches in width and up to 5 pounds in weight. Will not cause the robot to lose balance when the arm is fully extended and the gripper is

carrying an object.

The above specifications have been succinctly tabulated in Table 2.1 below.Table 2.1 : End effector motion

Range of rotation Plane or axis of movement

Time to completion

Pivoting shoulder joint 180o X-Y plane 3 sec.Retracting shoulder joint Zero to full extension Along X axis 4 sec.Pivoting elbow joint -90o to 90o Around X axis 3 sec.Rotating wrist joint 90o Forearm axis 3 sec.Opening/Closing gripper 80o Normal plane 3 sec.

Each degree of freedom has a dedicated motor. Servo motors will be used to allow for control via a feedback control algorithm. Rotational pivots utilize worm gear drive systems to lock systems in position when not activated. Critical sections of the arm were analyzed to assure that stresses seen at operational loads would not cause them to fail. Physical dimensions of the entire assembly are given in table 2.2. A detailed look at the weight of individual end effector components, including motors, are given in Tables 2.3 – 2.8 on the next page.

Table 2.2 : Physical dimensions of the end effector

Value UnitsLength 20 in.Width 4 in.Height 5 in.Weight 7.5 lb.

9

Ongo-01: Team OSCAR

Table 2.3 : Weight of components in gripper

ComponentUnit

weight (lb)

Qty Total

Small worm block 0.02 1 0.02Large worm block 0.07 1 0.07Clamp plates 0.10 2 0.2Worm gear 0.13 2 0.26Worm 0.07 1 0.07

Total 0.62

Table 2.4 : Weight of components in forearm

ComponentUnit

weight (lb)

Qty Total

Worm gear 0.62 1 0.62Worm 0.07 1 0.07End plate 0.15 1 0.15Center plate 0.08 1 0.08Forearm rods 0.04 3 0.12Claw motor 0.50 1 0.50

Total 1.54

Table 2.5 : Weight of components in wrist

ComponentUnit

weight (lb)

Qty Total

Worm gear 0.62 1 0.62Worm 0.07 1 0.07Clamp plate 0.03 1 0.03Roller taper bearing 0.13 1 0.13Length plate 0.11 2 0.22Bearing spacer 0.03 1 0.03Wrist motor 1.50 1 1.50

Total 2.6

Table 2.6 : Weight of components in upper arm

ComponentUnit

weight (lb)

Qty Total

Upper arm body 0.68 1 0.68Vertical plate 0.19 1 0.19Side supports 0.05 2 0.10Elbow motor 2.00 1 2.00

Total 2.97

Table 2.7 : Weight of components in base

ComponentUnit

weight (lb)

Qty Total

Cart 0.780 1 0.780Rail 0.440 2 0.880Linear gear 3.190 1 3.190Worm gear 1 0.310 1 0.310Worm 1 0.210 1 0.210Worm gear 2 0.130 1 0.130Worm 2 0.070 1 0.070End plate 1 0.550 1 0.550End plate 2 0.110 2 0.220Motor bracket 0.140 2 0.280Motor 1 1.500 1 1.500Motor 2 0.725 1 0.725

Total 8.845

Table 2.8 : Total weight of assembled components

Assembled Component

CombinedWeight

(lb)Qty Total

Gripper 0.620 1 0.620Forearm 1.540 1 1.540Wrist 2.600 1 2.600Upper arm 2.970 1 2.970Base assembly 8.845 1 8.845

Total end effector weight 16.58

10

Ongo-01: Team OSCAR

2.3 Technology ConsiderationsThe following section details some of the technological considerations inherent in this project.

2.3.1 Computer SystemThe existing CPU installed in the computer system is about five years old. As a result, its processing power is only about 25% that of modern computers. This creates a constraint for several technologies that might otherwise be integrated into the end product, including real-time audio and video processing. However, the end product only requires that the CPU can execute Java classes and support a limited list of speech commands. Nevertheless, a faster system will provide for improved Java execution and possibilities for extensive speech control. Further, the computer will also be required to control the end effector once a motor controller is selected. If interacting with the motor controller proves to be processor-intensive, a faster computer system would be necessary. The team will seek out donation of a new computer system as a first option. If this is not possible, essential components will be upgraded.

2.3.2 Speech RecognitionThe robot needs a way to interpret spoken commands in a non-processor-intensive manner in order to operate efficiently with the current processor. A program like IBM’s ViaVoice has been considered as a possible solution. After initial configuration, this software can understand a vast amount of spoken words. This may require too much processing power to conform to project limitations. Another option will be software that compares a list of known commands to the command that is spoken. With this method, the software only needs to know a small number of commands and does not need to concern itself with recognizing every word in the dictionary. Daniel Kiecza’s CVoiceControl is an example of this type of software. Research and further evaluation of these programs will be undertaken this semester.

2.3.3 Wireless ConnectionIn order to provide remote interaction with the robot it is necessary to provide wireless access to the onboard computer system. The best established methods for implementing wireless communication are serial radio links and 802.11 radio Ethernet. Serial radio links are very compatible with the current CPU processing unit because they require no software to drive them. However, they are only one tenth as fast as 802.11 radio Ethernet links, and cost over $300 each. Since the recently-installed operating system has support for 802.11 radio Ethernet links, they will be the clear choice for the fastest speed and lowest cost.

2.3.4 Power UsageMethods of converting a raw power signal from the batteries into signals that are usable by the computer system and the motion systems have been researched. Currently, the DC/AC inverter supplies 250W of power. There have been problems with this inverter because it has overheated during multiple demonstrations. The purchase of a larger 500W DC/AC inverter over an ATX DC power supply will be the most economical way of reliably supplying the computer with power. However, in the event that the team is given a new computer system, power requirements

11

Ongo-01: Team OSCAR

may change based on the power it requires. Research into further options is a projected task for this semester.

2.3.5 End EffectorSolutions for controlling the movements of the end effector assembly must be researched. Control units bought from third-party manufacturers will be compared to units designed and built by the project team. Alternatives will be considered with respect to size, cost, ease of interface with the computer system, and power load.

New technology considerations for the end effector include: Material selection for the end effector must provide adequate strength with minimal

weight, and must not surpass the project budget. Potential materials include steel, aluminum alloys, and composites such as Kevlar®, fiberglass, and carbon fiber.

Motors, such as servo gear motors, must be selected to actuate the range of motion of the end effector. Motors currently available to the team will always be used whenever possible.

Different types of metal gears will be used to transform the angular motion of the motor to obtain the desired movement in the end effector, including worm gears, spiral bevel gears and helical gears.

A high-friction material, such as viton or Super Grip®, should be applied to the gripper on the end effector to improve friction and gripping capabilities.

2.4 Technical Approach ConsiderationsThe following section details some of the methods used in completing the project.

2.4.1 General ConsiderationsThe following considerations relate to the project as a whole.

2.4.1.1 Team sizesA single, large team that is collaboratively focused on an individual task would make organization easier, and it would also most likely complete a single task much more quickly than a smaller team, but with much more overlap of responsibility. A single large team is not as greatly affected by the loss of a team member as multiple small groups.

Multiple groups working on individual tasks allow concurrent task development. They allow a more detailed specification of precise requirements and design by allowing a smaller group to focus specifically on one portion. These groups are also generally more efficient than one large group. Thus, project resources will be divided into three subgroups, namely, sensors, software, and electromechanical. Resources will be transferred between groups as necessary in order to complete tasks on schedule.

2.4.1.2 DecisionsA democratic approach to making decisions ensures that everyone’s voice is heard during the design process. Decisions are made more slowly; however, the quality of these decisions is likely to be higher.

12

Ongo-01: Team OSCAR

A centralized/authoritarian approach to decision-making ensures that decisions are made swiftly and helps eliminate misunderstandings about what precisely is to be done, but input from only one team member is considered. As a result, however, the quality of the decisions made can be poor, particularly if the person making them is misinformed.

2.4.2 Design and Implementation ApproachImplementation of solutions into the end product shall conform to the general design approach described in Figure 2.3. First, methods to solve the task at hand will be researched and considered. Based on efficiency, conformity to design constraints, and cost, a solution will be selected. Design, implementation, and testing occur if the solution is something that was not prefabricated. If testing proves unsatisfactory results, modifications will be made to improve upon the design. In the event that a prefabricated solution is unsatisfactory, modifications will be attempted to achieve more desirable results. If nothing is successful, however, a new solution will have to be considered. Special care must be taken to ensure that prefabricated solutions will work properly with the overall design. Once the solution is developed, it will be implemented into the system and appropriately documented.

13

Ongo-01: Team OSCAR

Research solution alternatives Select a solution

(Re)Design solution

Build a prototype

Are the results satisfactory?

Test the solution

Implement the final solution into the

system

Produce design and support

documentation

No

Yes

Was the solution prefabricated?

No

Yes

Figure 2.3 : Technical approach flow chart

2.5 Testing Requirement Considerations The following sections document the necessary considerations for the testing of the end product.

2.5.1 New software testingType of test: Code shall be tested by attempting to use it in accordance with its intended

function. For instance, sensor code must reflect sensor input, as defined by specifications, and electromechanical code must control the robot. The software will be implemented according to design requirements and subsequently tested by running the software on the robot. Tests performed will be as exhaustive as possible by providing multiple inputs and

14

Ongo-01: Team OSCAR

different scenarios. Software will be modified when results do not conform to design requirements.

Acceptance Criteria: The software must perform as expected for each situation tested.

2.5.2 Speech recognition testingType of test: There are a few factors that will effect the quality of the speech

recognition software. First, the microphone needs to be tested to confirm that the software is getting the signal at high enough volume level. A pre-amplifier can be installed if the signal is too low. Second, an ideal command length needs to be determined. Too short of a command may cause the software to confuse the command with others, too long of a command will take too long to process. Different methods of issuing commands will be tested by speaking them to the robot. Once an appropriate style of command is chosen, the robot can be tested for correct functionality given a command.

Acceptance criteria: Given an existing the command, the robot will carry out the corresponding operation.

2.5.3 Automated software testingType of test: To ensure a more reliable overall software package, automated software

testing will be developed. JUnit, a testing program for Java classes, will be used to test the entire software package at once. The program defines expected results for certain ranges of input. Large amounts of inputs are then put through the software package. This allows changes to be tested in a quick and consistent manner.

Acceptance criteria: For each input tested, the actual result will match the expected result.

2.5.4 Signal output of wheel tachometer circuitType of test: Once a circuit has been implemented, a wheel tachometer will be

manually rotated. The output of the circuit will then be measured and analyzed with a voltmeter.

Acceptance criteria: The output of the circuit should be an analog 2.5-5.0Vdc when the tachometer shaft is moving forward, and 2.5-0.0Vdc when moving in reverse. The actual voltage level will be dependent on the speed of rotation.

2.5.5 Computer power supplyType of test: To make sure a fully charged battery is supplying enough power to the

computer, it will stay connected to a running computer for a period of two hours.

Acceptance criteria: The computer is still fully operational after two hours has passed.

15

Ongo-01: Team OSCAR

2.6 Security ConsiderationsSeveral security considerations must be taken into account during the project.

2.6.1 Project Development The end product and all project equipment shall be kept in the OSCAR laboratory in Town Engineering Building. The laboratory door shall remain locked at all times, and access to its key shall be granted only to members of the project team, the project advisor, and the course coordinator. Unauthorized tampering with the equipment and the robot will thus be avoided.

Computer code written for the project shall be kept in a CVS repository. Write access to the repository shall be restricted to team members, the project advisor, and the course coordinator. This also provides a logging of code changes, and permits the team to roll back to a previous version should the integrity of the code be compromised.

2.6.2 End-Product Operation Remote connections to the robot shall be authenticated using a password to prevent unauthorized access.

Access to the internal components of the robot shall be guarded by lock. The key to open the lock shall be made available to team members, the project advisor, and the course coordinator. Views of the locked façade and opened access door are shown in below:

Figure 2.4 : Locked façade and opened access door

16

Ongo-01: Team OSCAR

2.7 Safety ConsiderationsTo ensure the safety of the end product and the team members alike, the following guidelines shall be followed:

Wiring shall be placed away from moving parts. All wiring installed shall be rated to conduct the current drawn through it. All battery connectors shall be covered with resistive material to prevent electric shock. All connections between internal components and the batteries shall be fused. A mechanical emergency stop disconnect shall be installed between the power system

and each electromechanical component controlled by the computer system. External mechanical components shall have no loose cabling or externally accessible

gears. All moving parts shall be covered to prevent injury to the end-user. All fabrication processes shall follow procedures and regulations defined by the Iowa

State University Environmental Health and Safety office. The software shall be implemented to terminate all actions and motion if the connection

is lost between the client and server.

2.8 Intellectual Property ConsiderationsAll technologies created and research performed while developing the project shall conform to the guidelines of the Iowa State University Student Handbook.

2.9 Commercialization ConsiderationsThis product will not be commercialized for private or public sale. It is designed solely for the purpose of technological demonstration, and shall be in the ownership of Iowa State University.

2.10 Possible Risks and Risk ManagementRisks were identified and categorized according to their risk level (see §4.3.3: Risk Assessmentmethod).

2.10.1High-Level RisksThe following section details some of the high-level risks anticipated during this project.

2.10.1.1 Equipment failureEquipment failure during or prior to use forces the development process to halt until the equipment is either repaired or replaced. To minimize down time, functioning auxiliary equipment shall be made available whenever possible. (Equipment is expensive, and the team is unable to purchase secondary units to every piece of equipment used. Certain items, however, can be stocked in duplicate.)

17

Ongo-01: Team OSCAR

2.10.1.2 Failure to complete assigned tasksBecause many tasks are dependent upon the completion of others, the failure of a team member or team members to complete an assigned task under budget and prior to the deadline could threaten the entire project. The project is currently on schedule to have all end product deliverables ready by next semester, so it is crucial that scheduled tasks are completed. This situation shall be avoided through proper tracking of task progress. In the event that a task misses its deadline, extra resources will be applied to the task until it is complete. As a last resort, incomplete tasks will be extended to next semester.

2.10.2Medium-Level RisksThe following section details some of the medium-level risks anticipated during this project.

2.10.2.1 Unauthorized spoken commandsWith the implementation of speech control, the risk of unauthorized users issuing commands to the robot is possible. During all presentations, the audience will be advised as to what times are acceptable to issue commands to the robot. Of course, spoken commands can be terminated through the software or through the manual emergency stop button. The robot will also be programmed in a manner which limits its responses to spoken commands. Invalid commands will be either ignored to ensure safety.

2.10.2.2 Ordered parts do not arrive on timeParts or components ordered from a third-party distributor for use in the project may not be delivered within the expected timeframe. This could delay further development of the project. To minimize the effect of this risk, extra time for part delivery will be anticipated and allotted.

2.10.2.3 Cost of development exceeds expectationsFabrication and assembly of the end effector may prove to be an expensive process. Should mechanical expenses overwhelm the project budget, this task will be halted. To minimize costs, as much of the machining and assembly as possible shall be done by students, using Iowa State University facilities. Existing motors from previous arm assemblies will be used in the end effector design. Any components deemed too complex to fabricate and too expensive to buy directly will either be reused from existing assemblies or acquired from companies through sponsorships or in-kind donations.

2.10.2.4 Machining tragedyAs machining duties will be carried out by students, there is a danger to both operator and machine that damage may result from improper machining practices. To avoid such problems, any student who will carry out such work will take personal responsibility to learn how to properly use the machine according to standard operating procedures before doing so. Other members will also take the responsibility of enforcing this policy.

18

Ongo-01: Team OSCAR

2.10.3Low-Level RisksThe following section details the low-level risks anticipated during this project.

2.10.3.1 Software testing shows bugs in codeDuring testing, bugs in the software will inevitably appear and require additional time to fix them. If sufficient time is not given to the debugging process, either unallocated time must be spent debugging software (which deviates from budget and resource constraints), or the bugs must be left in the software, which may cause malfunction in the end-product. To avoid either of these situations, software bugs shall be prioritized according to their risk to the software system and repaired in order of decreasing priority.

2.10.3.2 Failure to attend a meetingFailure of a member of the team to attend any meeting could result in a communication gap, which easily translates to improper design and wasted resources. When a member of the team misses a meeting pertinent to that member’s assigned tasks, a report of the meeting shall be generated and sent via e-mail to the absent member. This report will be generated by the person who conducted the meeting.

2.11 Proposed Milestones and Evaluation CriteriaThe following section documents the proposed milestones and how they will be evaluated.

2.11.1Project MilestonesThe following are the proposed milestones for this project:

2.11.1.1 Technology selectionContemplation and choice of available technologies for design implementation will be performed prior to design and implementation of new solutions.

2.11.1.2 End product designDesign of components or functionalities to be integrated into the end product

2.11.1.3 End product implementationConstruction or addition of components into end product

2.11.1.4 End product testingTesting of components and overall end product for conformity to functional requirements and design constraints

2.11.1.5 End product documentationReference materials for new components implemented on the robot shall be created to aid future modification and maintenance of the end product. These materials include schematics, interface documentation, testing procedures, user manuals, and maintenance procedures

19

Ongo-01: Team OSCAR

2.11.1.6 Project reportingCreation and delivery to the client of the following progress reports shall be performed: Project plan document Poster Status report document Industrial review panel presentation Weekly e-mail reports Website maintenance

2.11.1.7 End product demonstrationDemonstration of the functionalities of the end product to interested parties.

2.11.2Evaluation CriteriaThe milestones shall be prioritized according to Table 2.9. These milestones were evaluated based on a method of task urgency and required effort, discussed in 4.3.2: Milestone priorityassignment method. Table 4.20 : Project priority assignment chart for milestones, is a detailed version of Table 2.9 that shows the priority percentage for each task included in each milestone. Table 4.14, Table 4.15, Table 4.16, and Table 4.17 specifically show the priority grids for sensory tasks, software system tasks, electromechanical system tasks, and general tasks, respectively. Upon the completion of the project, each milestone shall be evaluated according to the amount of progress made toward that milestone, and comparing its projected results with its attained results. As a whole, this evaluation of the completed milestones can be used to quantitatively analyze the progress which has been made, and this information can be used to make recommendations for further work (see §2.12.2: Internal project tracking).

Table 2.9 : Milestone Prioritization

# Milestone Priority (%)1 End product implementation 332 End product design 173 End product testing 154 End product demonstration 125 Technology selection 116 Project reporting 87 End product documentation 4

20

Ongo-01: Team OSCAR

2.12 Project Tracking Procedures This section documents the tracking procedures which will be used during the course of work this semester.

2.12.1Project reportingFormal reporting methods, such as document releases and placing posters in public view, shall be used to maintain public knowledge of the project’s goals and scope. Informal reporting methods, such as email reporting and maintenance of a project website, shall be used to provide access to the project’s immediate completion status.

Formal reporting methods that shall be used include: Release of a Project Plan document to propose intended project accomplishments for the

current semester. Creation and display of a poster that shall briefly detail the current project efforts and

their expected outcomes. Release of a Status Report document to review conformity to the Project Plan document

over the current semester. A presentation of current project accomplishments and shortcomings to an industrial

review panel.

Informal reporting methods that shall be used include: Individual team member status reports that are created weekly and emailed to the project

advisor and course coordinator. Maintenance of a project website, on which contact information, copies of release

documentation, and current project status information will be made available to the public.

2.12.2Internal project trackingThe project will be tracked at weekly meetings by updating a progress chart (see §4.3.4: Progress chart example). Progress on a task shall be reported at each weekly team meeting as the percentage of that task’s total labor that has been completed. Expenditures shall also be reported and tracked against the total task budget. This will facilitate immediate tracking of project progress and correction of deviations from expected resource scheduling.

2.13 Statement of WorkThe following section describes the work to be done this semester in detail.

2.13.1Technology selectionThe following section documents the criteria and methodology for selecting certain technologies.

21

Ongo-01: Team OSCAR

2.13.1.1 Select speech recognition softwareObjective

One of the project’s overall goals is to provide a feature which allows the robot to be controlled by voice. Software providing this functionality needs to be evaluated and chosen.

Approach

As a part of the end design, speech recognition software needs to be added to the robot which will allow it to obey commands issued by voice. As the first step toward reaching this goal, currently-existing speech recognition software must be identified, evaluated, and tested to determine whether it meets the requirements of this project.

Expected ResultsSoftware capable of some form of speech recognition will be available.

2.13.1.2 Select I/O interface for end effectorObjectiveAn I/O interface to communicate between the computer and the end effector will be evaluated and chosen.

ApproachAs a part of the development of the control structure for the end effector, an I/O interface must be chosen. A serial port is likely the most effective way to communicate with the end effector’s control circuit. However, this is complicated by the fact that there are no more serial ports available for use by the robot. If an additional serial port is needed, a USB-to-serial adapter will likely be the best solution. Otherwise, additional interfaces will have to be identified and evaluated for use in controlling the robotic arm.

Expected ResultsA method to reliably communicate between the computer and the end effector will be available.

2.13.1.3 Consider end effector control solutionsObjectiveThe end effector assembly will be driven by electric motors. A method of controlling these motors will be necessary to use them. The most economical and effective controller must be chosen.

ApproachSolutions to be considered include:

Technologies developed by past project teams Commercial solutions Development of new technologies

22

Ongo-01: Team OSCAR

Previous control implementations were centered on the National Semiconductor LM628/LM629 chip and the Linear Technology LT1158 chip (see §4.3.5: Specifications for potential controlsolutions). These solutions were abandoned because of the current load requirements in their previous implementations, but they may prove viable for the small motors on the end effector unit. If so, one of them could be the most economical solution, since all research and design have already been completed.

A commercial controller is a viable option because of the decrease in design effort, but price is a constraint. EBay® could be an excellent source for a commercial motor controller. National Instruments will also be a place to search for donated equipment since they have been past financial supporters of senior design activities.

If neither of these solutions seem viable, it may be necessary to design and build a circuit to act as the motor controller. This is would be a time consuming and potentially costly option.

Expected ResultsA reliable, economical control solution for the end effector will be available.

2.13.1.4 Consider end effector hardware solutionsObjectiveThe end effector assembly will be created using numerous gears and links in order to correspond to the design specifications currently documented.

ApproachFirstly, equipment needed to create the end effector will need to be acquired. Servo motors that will fit the design are available from previous arm designs, but another motor may still be needed. The frame hardware and other required links will need to be acquired at minimum cost. Donations from faculty or vendors will be a sensible approach for the acquisition of these parts.

Expected ResultsAll components necessary to implement the end effector will be available.

2.13.1.5 Consider purchase of DC/AC inverterObjectiveThe 250W DC/AC inverter currently installed in the robot is overheating and causing the computer to shut down after minimal operation. A solution must be found which will provide sufficient power to the computer from the battery without overheating.

ApproachIn previous semesters, power solutions have been investigated. A DC/DC converter could be installed as a replacement for both the inadequate DC/AC inverter and the computer’s internal power supply. However, after some research, it was determined that this route would be too expensive and that the converter may not even be able to supply sufficient power to the computer. A replacement DC/AC inverter could be purchased to for significantly less money. An inverter capable of producing 500W or more of output would be powerful enough to handle the

23

Ongo-01: Team OSCAR

present computer system and any foreseeable future upgrades to the computer. Last semester, a consensus was reached that purchasing a new 500W or larger DC/AC inverter would be beneficial to the project. Further, a new computer system obtained by means of a donation, may be installed on the robot. If this occurs, the need for a new power supply will be reconsidered based on the power requirements of this new system.

Expected ResultsIf a new power supply is needed, the chosen product will be purchased, shipped, and installed on the robot. The new power solution will allow continuous operation at full power for longer periods of time.

2.13.2End-product designThe following section describes the work to be done on the end-product design.

2.13.2.1 Design wheel tachometer circuitObjectiveA wheel tachometer circuit will be designed to interface with the current robot motor controller.

ApproachOne robot wheel spins at a slightly different rate than the other, causing forward movement to not occur in a straight line. Wheel tachometers are ready to be installed, but, they do not correctly interface with the existing motor controller. A circuit needs to be developed to send the correct input to the motor controller from the wheel tachometer output.

The wheel tachometer will provide connectivity to the rotary shaft of the motor. The tachometer should encode the input signals and provide two streams of the output to the circuit, namely channel A and channel B. Channel A will be given directly to a multiplexer and Channel B will be sent through a frequency-to-voltage converter, and ultimately sent to the multiplexer. The multiplexer then decides which signal to pass on. It will either pass a forward voltage (2.5V - 3.0V) for a high bit or a reverse voltage (0.0V - 2.5V) for a low bit.

Expected ResultsA detailed circuit design to interface with the motor controller will be ready for implementation.

2.13.2.2 Design software to interact with wheel tachometersObjectiveIn order to implement distance-based motion commands, software needs to be designed or extended to interact with the wheel tachometers. ApproachCurrently, the robot moves by commanding the robot to move for a set amount of time. With the addition of wheel tachometers, functionality can be added to move the robot a set distance. This motion could either be in a straight line, or in vector form, with direction and magnitude. Mathematical calculations will need to be done so that distances can be converted to information

24

Ongo-01: Team OSCAR

that the motor controller can use. Further, this design will also have to be extendable to implement the mapping functionality.

Expected ResultsDesign requirements to implement software that will allow distance-based motion control commands will be available.

2.13.2.3 Develop navigation algorithmObjectiveAs an added feature to the robot end product, the robot should be able to autonomously move through a room or hallway without running into any walls or obstacles. Once the SONAR array has been fixed and characterized, the algorithm can be implemented into the robot’s operating procedures.

ApproachComputation techniques for basic robot behavior and coordination of basic navigation plans will be investigated. The algorithm which would best suit the sensor array’s functional requirements (object avoidance) can then be determined. Sources will include case studies and collaborative assistance. For the robot’s eventual full autonomy, mapping or other complicated data analysis algorithms will also be required.

Expected ResultsA navigational algorithm based on the available control and sensors will be described that can then be implemented in software to provide autonomous navigation.

2.13.2.4 Design end effector controllerObjectiveThe end effector needs a reliable multiple-channel controller for its motors. If commercial controllers cannot be implemented or are not a viable option, a controller shall be designed.

ApproachThe simplest solution is to update a pre-existing design that was used for motion control. This design includes the LM629 and the LT1158 (see §4.3.5: Specifications for potential controlsolutions). Previously, problems arose with the chips burning up due to the high current load from the motors. However, because the end effector motors are much smaller, this will be the best solution. Whether by updating the previous design or starting from the beginning, to be effective, the outcome will have to meet the load requirements designated by the end effector design constraints.

Expected ResultsA detailed design for the end effector control circuit will be available that conforms to the design constraints placed upon it by the end effector.

25

Ongo-01: Team OSCAR

2.13.3End product implementationThe following sections describe the work to be done on the implementation of the end product.

2.13.3.1 Implement speech recognitionObjectiveThe goal is to implement the speech recognition software what was selected previously in the speech recognition software selection task.

ApproachOnce effective speech recognition software is selected, it will subsequently be installed and tested using simple test cases to make sure the base functionally exists. Software will then be implemented to utilize the speech recognition in order to issue the robot commands through speech. This will involve defining a set list of commands that the robot will be able to recognize and respond to accordingly.

Expected ResultsThe robot can understand and respond to a limited set of command words. These commands will encompass all basic features of the robot.

2.13.3.2 Revise existing GUI softwareObjectiveA fully operational GUI software package was developed last semester. As the project progresses, certain features need to be added, and existing features need to be improved in order to increase the performance and usability of the existing functionality.

ApproachFirstly, the existing code to connect to the robot over the wireless network needs to be improved. This will be done by the use of threads in order to create independence between execution of the network code and the GUI. Therefore, the GUI will stay responsive at all times. Further, the interface to play and record scripts needs to be implemented on the client side. This will allow a user to replay actions just as they were entered into the GUI originally. Error handling will be implemented as well so that the software is robust enough to recover from network problems as well as bad input. Additional features will be added as needed all in an effort to improve the software.

Expected ResultsThe existing GUI software package will further encompass the entire functionality of the robot in an interactive and responsive manner.

26

Ongo-01: Team OSCAR

2.13.3.3 Implement wheel tachometer circuitObjectiveA wheel tachometer circuit will be constructed from the design, and integrated into the current drive system.

ApproachFollowing the final design, the circuit will be constructed using purchased or donated components. Certain components will be fabricated from custom designs. All components will then be installed on the circuit board, connections will be properly soldered, and the microcontrollers will be programmed accordingly.

Expected ResultsA circuit capable of interfacing the existing wheel tachometers with the motor controller will be available.

2.13.3.4 Implement software to interact with wheel tachometersObjectiveA software controller interface will be written to communicate with the newly installed tachometer circuit for the purpose of distance and position control.

ApproachSoftware will be written that will adjust the wheel motors to move the robot a certain distance. The software will use wheel tachometer output received from the motor controller to figure out how to adjust the wheel motors. This software will follow the previously-developed design (see §2.13.2.2: Design software to interact with wheel tachometers).

Expected ResultsSoftware will be developed which is capable of commanding the robot to move according to distance input.

2.13.3.5 Install wheel tachometersObjectiveThe newly-developed tachometer circuit will be installed in the current drive system.

ApproachA suitable mounting position will be found for the tachometers so as not to interfere with the motion of the wheels. After mounting, the tachometers will then be wired to interface with the motor controller. The software controls will then be added to the current system’s navigation controls

Expected ResultsThe rotation of the wheels will be controlled by a circuit based on the differential of rotation of the two drive wheels, rather than the voltage input given to the drive motors. The software interface will be given monitoring data on wheel rotations for distance and position calculations.

27

Ongo-01: Team OSCAR

2.13.3.6 Repair SONAR arrayObjectiveA functioning SONAR array will output accurate environmental data to computer.

ApproachThere are several important steps in the repair off the SONAR array. First, transducer functionality must be confirmed by triggering a rising edge INIT pulse and measuring the return ECHO delay. This can be done using a two-channel oscilloscope and one SONAR array module connected to a transducer. The accuracy can be confirmed by calculating the distance to a known object using the delay between pulse and echo.

Second, communicating with the BasicX-24 microcontroller will determine what, if any, data resides on the EEPROM for SONAR programs. Isolating the BX-24 on a breadboard and putting it in communication mode will allow a computer to communicate with the microcontroller. Should it be necessary, a new control program will be written. Once a usable program is available, it will be tested with a transducer and array module for functionality.

Expected ResultsAll eight transducers will be firing accurately and producing meaningful data about the robot’s surroundings. The gathered data will be communicated to the computer controlling the robot.

2.13.3.7 Implement new end effectorObjectiveBased on the detailed design developed last semester, the end effector will be constructed and mounted to the robot. Currently, the outcome of this task depends on the mechanical engineering student resources our group is given.

ApproachFollowing the final design, an end effector will be constructed using in-house machined components as well as specified purchased items. These will be determined based on the selection of the end effector hardware components (see §2.13.1.4: Consider end effectorhardware solutions).

Certain components will be fabricated from custom designs. To complete this task, group members will be assigned certain components to take full construction responsibility using facilities on campus (such as Department of Mechanical Engineering machine shops and the Society of Automotive Engineers shop). Machining duties will include, but not be limited to, turning, milling, drilling, sawing, bending, welding, and threading.

Final assembly will begin once all components are obtained or fabricated. During this time, components will be configured according to the final design, given any special treatment (such as lubrication), and modified to operate correctly should any issues be discovered (such as clearance, binding, etc.).

Expected Results

28

Ongo-01: Team OSCAR

When completed, the end effector will be mounted onto the robot. Since the control system will not be implemented this semester, showcasing the end effector will be done manually. Testing will have assured acceptable motion capability, and assessed the lifting capacity of the end effector system.

2.13.4End-Product TestingThe following sections document the testing to be done on the end product.

2.13.4.1 Characterize SONAR arrayObjectiveDetermine the three-dimensional range of the SONAR in terms of radius, height, resolution, and distance.

ApproachObjects of various heights and spatial arrangements will test the robot’s transducers’ effective detection range. To test the position limitations, an object will be placed directly in front of the transducer and moved towards the robot until it is not detected. This point will be recorded. The object will then be moved away from the robot until it is again no longer detected, and that point will also be recorded. For peripheral detection, an object will be placed at 15 feet from the robot and moved to each side until it is no longer detected. Once the boundaries are known, objects of different heights and sizes will be checked for detection using the same method.

Expected ResultsA map of data points will be developed which show the inclusive range of the transducer detection area. Further, the team will gain important insight into the capabilities of the SONAR array.

2.13.4.2 Test newly developed softwareObjectiveTesting of the software for speech control, the GUI, and any created scripts and macros will be performed for individual accuracy and cohesion with all other aspects of the system.

ApproachTesting will be an ongoing part of the project process. After speech recognition software is implemented, we will test the accuracy of our command list simply by speaking them. If the software does not respond well to certain words, updates will be made. The GUI will be tested to check that the commands on the screen are corresponding to the correct functions on the robot. In turn, the feedback will be checked as well to determine that the robot is sending back the correct information.

Expected ResultsAll new software written for the robot will be debugged and reworked according to test results. Software will then be in its most optimal form.

29

Ongo-01: Team OSCAR

2.13.4.3 Automate software testingObjectiveA set of tests will be created to verify that additions and updates to the software do not break currently implemented basic functions of the software system.

ApproachEach class or program will have a list of test cases created that are designed to verify the software is correctly performing all functionality. Tests will fail if expected output does not match actual output when certain ranges of inputs are tested. Ultimately, a script will be made to execute each test case and verify the output with the expected output.

Expected ResultsA set of scripts will automatically test the software’s functionality and report back any errors that occurred from code changes.

2.13.4.4 Test new end effectorObjectiveThe newly built end effector will be fully tested for confirm the current functionality requirements and an assessment of the system’s capabilities will be made.

ApproachOnce the end effector is completed, the range of motion will be tested. By simply connecting a DC source to the motors individually the movement of the arm will be tested.

Expected ResultsCompletion of end effector testing will produce documentation defining the systems motion capabilities (such as actual range of motion) and lifting capacity. These results will be compared to what was expected during calculations.

2.13.5End-Product DocumentationThe following section describes the documentation to be done for the end product.

2.13.5.1 Document wheel tachometer circuitObjectiveDocumentation of the circuit design and schematic will be created in order to implement and integrate the tachometer into the current system.

ApproachUsing Auto-Cad or another suitable software to create a schematic a circuit will be designed and added to the file server. Along with the schematic design all component research will be documented and put into a final report for the tachometer design.

Expected ResultsWhen completed future team members will have a well documented design with which they will be able to implement with little difficulty.

30

Ongo-01: Team OSCAR

2.13.5.2 Document newly developed softwareObjectiveDocumentation will be written for the newly developed software as well as updating the current documentation of any changes to the current software system.

ApproachWhile new code is being developed, useful comments and Javadoc® will be continuously added which will explain the function and purpose of the code. Class comments will be used which explain the methods and function of the class and its methods.

Expected ResultsNew code on the robot will be documented so that future teams will be able to use it without having extensive studying of the code.

2.13.5.3 Document end effector controllerObjectiveDocumentation of the circuit design, schematic and software interface will be created in order to implement and integrate the end effector into the current system.

ApproachUsing Auto-Cad or another suitable software to create a schematic a circuit will be designed and added to the file server. Along with the schematic design all component research will be documented and put into a final report for the controller design.

Expected ResultsA well documented control circuit design will be readily available for future team members to implement.

2.13.6End-Product DemonstrationThe following section describes the demonstrations to be done with the end product.

2.13.6.1 Present robot to campus visitorsObjective

As the guiding objective of this project is to provide a tool for the College of Engineering to use in its demonstrations to campus visitors, some time has been set aside to present the robot to visitors in its current form.

Approach

Though the project has not yet been completed, there is enough functionality that the robot can be shown to campus visitors. On days when the robot has been requested for a demonstration, team members will assemble no less than a half hour beforehand to prepare the robot and do any required last-minute troubleshooting. The robot will then be taken to the location of the

31

Ongo-01: Team OSCAR

demonstration and be presented. Afterward, the robot will be taken back to the lab to recharge the battery for the next presentation.

Expected Results

It is expected that after the demonstration of the robot, prospective students will have a better idea of what engineers at Iowa State University do.

2.13.6.2 Develop scripts and macrosObjectivePreprogrammed, executable instruction sets shall be developed for use in demonstration of the end product’s capabilities.

ApproachThe end product will be pre-programmed to utilize its features in a demonstration setting. It will operate independent of manual control.

Expected ResultsScripts and macros that can demonstrate the robot’s abilities shall be developed.

2.13.7Project reportingObjectiveTracking and public disclosure of project progress shall be maintained through timed document releases and presentations. These will include a project plan, project poster, status report, and a presentation to the Industrial Review Panel.

ApproachCollaborative meetings shall be held to plan and create each deliverable report.

Expected ResultThe client and any interested parties shall be kept up to date with current project progress.

32

Ongo-01: Team OSCAR

3 Estimated Resources and Schedules

3.1 ResourcesTo compact the large tables associated with this section, all tasks are referenced by their task number. Table 3.10 is a reference chart for the descriptions of these tasks.

Table 3.10 : Task description reference chart

Task Number Task Name2.13.1.1 Select speech recognition software2.13.1.2 Select I/O interface for end effector2.13.1.3 Consider end effector control solutions2.13.1.4 Consider end effector hardware solutions2.13.1.5 Consider purchase of DC/AC inverter2.13.2.1 Design wheel tachometer circuit2.13.2.2 Design software to interact with wheel tachometers2.13.2.3 Develop navigation algorithm2.13.2.4 Design end effector controller2.13.3.1 Implement speech recognition2.13.3.2 Extend existing GUI software2.13.3.3 Implement wheel tachometer circuit2.13.3.4 Implement software to interact with wheel tachometers2.13.3.5 Install wheel tachometers2.13.3.6 Repair SONAR array2.13.3.7 Implement new end effector2.13.4.1 Characterize SONAR array2.13.4.2 Test newly developed software2.13.4.3 Automate software testing2.13.4.4 Test new end effector2.13.5.1 Document wheel tachometer circuit2.13.5.2 Document newly developed software2.13.5.3 Document end effector controller2.13.6.1 Present robot to campus visitors2.13.6.2 Develop scripts and macros2.13.7 Project reporting

33

Ongo-01: Team OSCAR

3.1.1 Personnel effort requirementsRequired personnel effort is listed in Table 3.11 and Table 3.12. The listing was broken into two tables to ease display and readability; the sum shown at the end of Table 3.12 is for all tasks listed in both tables. Estimated time requirements for the tasks requiring mechanical engineers (tasks 2.13.1.4, 2.13.3.7, and 2.13.4.4) are currently unavailable, as there has not yet been time to get an estimate from them. These sections will be updated when the information is available.

Table 3.11 : Estimated personnel requirement 1

Personnel name

2.13.1.1

2.13.1.2

2.13.1.3

2.13.1.4

2.13.1.5

2.13.2.1

2.13.2.2

2.13.2.3

2.13.2.4

2.13.3.1

2.13.3.2

2.13.3.3

2.13.3.4

2.13.3.5

2.13.3.6

2.13.3.7

Sub-total

Kevin Cantu     10     4     25     8   2 21   70Philip Derr               19             24   38Jawad Haider     10     3      15     6   4     42David Hawley                     30           30Zachary Kotlarek 4                 30             34Michael Larson               20             25   45Jeff Parent   6               10         22   38Justin Ramussen   4         5           8   21   38Gavin Ripley   5         8           13       26Peter Rufino     8   10 4           12       34Jason Sytsma     20   2 3     23     10   4     62

Total 4 15 48 0 12 14 13 39 63 40 30 36 21 10 113 0 457

Table 3.12 : Estimated personnel requirement 2 (continuation)

Personnel name

2.13.4.1

2.13.4.2

2.13.4.3

2.13.4.4

2.13.5.1

2.13.5.2

2.13.5.3

2.13.6.1

2.13.6.2

2.13.7

Total

Kevin Cantu          4   6 2   13 95Philip Derr 25             2   21 91Jawad Haider         2   8 1   19 68David Hawley   5       15   2 3 20 75Zachary Kotlarek   4 15     4   3 2 22 84Michael Larson 26             2   18 91Jeff Parent   6       6   2 4 25 81Justin Ramussen   5           3 3 31 80Gavin Ripley   3       5   10 5 35 84Peter Rufino         4   2 1   21 62Jason Sytsma         3   10 2   20 97

Total 51 23 15 0 13 30 26 30 17 245 908

34

Ongo-01: Team OSCAR

3.1.2 Financial requirementsRequired financial resources are shown in Table 3.13. Sums are given with consideration for estimated labor costs and without, since the team members are not paid for their labor.

Table 3.13 : Estimated project costs

Parts and Materials   W/O labor With Labor DC/AC Inverter $ 100.00 $ 100.00 LS7184 Phase detector Donated Donated AD8170AN Multiplexer Donated Donated LM2907N-8 F-V converter Donated Donated Miscellaneous parts for assembly of final circuit $ 10.00 $ 10.00 Project Poster (including printing)   $ 35.00 $ 35.00

  Subtotal $ 145.00 $ 145.00

Labor @ $10.50 per hour      Kevin Cantu $ 997.50Philip Derr $ 955.50 Jawad Haider $ 714.00 David Hawley $ 787.50 Zachary Kotlarek $ 882.00 Michael Larson $ 955.50 Jeff Parent $ 850.50 Justin Ramussen $ 840.00 Gavin Ripley $ 882.00 Peter Rufino $ 651.00 Jason Sytsma $ 1,018.50

  Subtotal   $ 9,534.00   Total $ 145.00 $ 9,679.00

35

Ongo-01: Team OSCAR

3.1.3 Project scheduleThe overall project schedule is pictured in Figure 3.5.

Figure 3.5 : Overall project schedule

36

Ongo-01: Team OSCAR

4 Closing MaterialsProject team information

4.1.1 Client information---------------------------------------- Name: DEPARTMENT OF ELECTRICAL AND COMPUTER ENGINEERING COLLEGE OF ENGINEERING IOWA STATE UNIVERSITY Office Phone: 515-294-2664 FAX: 515-294-3637 Contact Name: PATTERSON RALPH III Email: repiii@iastate.edu Department: ELECTRICAL AND COMPUTER ENGINEERING Office Address: 2215 COOVER City/State: AMES, IA 50011 ----------------------------------------

4.1.2 Faculty advisor information---------------------------------------- Name: PATTERSON RALPH III Office Phone: 515-294-2428 Home Phone: 515-232-9933 Fax: 515-294-6760 Email: repiii@iastate.edu Department: ELECTRICAL AND COMPUTER ENGINEERING Title: ASST PROF Office Address: 326 TOWN ENGR City/State: AMES, IA 50011-3230 Home Address: 1807 24TH ST City/State: AMES, IA 50010-4403 ----------------------------------------

4.1.3 Student team information---------------------------------------- Name: CANTU L KEVIN Phone: 515-572-8129 Email: kcantu@iastate.edu Department: ELECTRICAL ENGINEERING Univ Address: 3433 FREDERIKSEN CT City/State: AMES IA 50010 Home City/State: OMAHA NE Classification: SENIOR ---------------------------------------- ---------------------------------------- Name: DERR PHILIP C Email: philderr@iastate.edu Department: ELECTRICAL ENGINEERING Univ Address: 200 STANTON AVE #306 City/State: AMES IA 50014 Home City/State: WHITING IA

37

Ongo-01: Team OSCAR

Classification: SENIOR ---------------------------------------- ---------------------------------------- Name: HAIDER MUHAMMAD JAWAD Phone: 515-572-7878 Email: jawadz@iastate.edu Department: ELECTRICAL ENGINEERING Univ Address: 4217 FREDERIKSEN CT City/State: AMES IA 50010 Home City/State: RAWALPINDI PUNJAB PA Classification: SENIOR ----------------------------------------

---------------------------------------- Name: HAWLEY DAVID A Phone: 515-572-5385 Email: davidhw@iastate.edu Department: COMPUTER ENGINEERING Univ Address: 5545 FRILEY NILESFOSTER City/State: AMES IA 50012 Home City/State: OSCEOLA IA Classification: SENIOR ----------------------------------------

---------------------------------------- Name: KOTLAREK ZACHARY PETER Phone: 866-863-8801 Email: profplum@iastate.edu Department: COMPUTER ENGINEERING Univ Address: 3604 ONTARIO ST City/State: AMES IA 50014-3911 Home City/State: ONALASKA WI Classification: SENIOR ----------------------------------------

---------------------------------------- Name: LARSON MICHAEL JEROME Phone: 515-572-6083 Email: larsonmj@iastate.edu Department: ELECTRICAL ENGINEERING Univ Address: 9106 BUCHANAN HALL City/State: AMES IA 50013 Home City/State: SOLON IA Classification: SENIOR ----------------------------------------

---------------------------------------- Name: PARENT JEFFREY DAVID Phone: 515-572-3066 Email: jparent@iastate.edu Department: COMPUTER ENGINEERING Univ Address: 2432 WILSON OWENS City/State: AMES IA 50013 Home City/State: BAILEYS HARBOR WI Classification: SENIOR ----------------------------------------

38

Ongo-01: Team OSCAR

---------------------------------------- Name: RASMUSSEN JUSTIN MICHAEL Phone: 515-598-9394 Email: jras@iastate.edu Department: COMPUTER ENGINEERING Univ Address: 200 STANTON APT 503 City/State: AMES IA 50014-6806 Home City/State: WEST DES MOINES IA Classification: SENIOR ----------------------------------------

---------------------------------------- Name: RIPLEY GAVIN D Phone: 309-678-3609 Email: ripoff1@iastate.edu Department: COMPUTER ENGINEERING Univ Address: 205 S 5TH ST #814 City/State: AMES IA 50010 Home City/State: WASHINGTON IL Classification: SENIOR ----------------------------------------

---------------------------------------- Name: RUFINO PETER OVU Phone: 515-451-3740 Email: prufino@iastate.edu Department: ELECTRICAL ENGINEERING Univ Address: 4912 MORTENSEN RD #813B City/State: AMES IA 50014 Home City/State: CEDAR RAPIDS IA Classification: SENIOR ----------------------------------------

---------------------------------------- Name: SYTSMA JASON RICHARD Phone: 515-491-6707 Email: jrsytsma@iastate.edu Department: ELECTRICAL ENGINEERING Univ Address: 6944 123 LN City/State: INDIANOLA IA 50125 Home City/State: INDIANOLA IA Classification: SENIOR ----------------------------------------

39

Ongo-01: Team OSCAR

---------------------------------------- Name: WALVATNE JOHN G Phone: 515-460-3616 Email: jwalvat@iastate.edu Department: MECHANICAL ENGINEERING Univ Address: 2627 KENT #27 City/State: AMES IA 50010 Home City/State: PARKERSBURG IA Classification: SENIOR ----------------------------------------

4.2 Closing SummaryThe Project OSCAR team is faced with the challenge of designing and implementing a robot to be used as a demonstration of the technical skills which graduates of Iowa State University possess. In the spirit of that charter, OSCAR will be used as a recruiting tool and as a highlight of the electrical, mechanical, and computer engineering programs. As universities across the nation are striving to prove that their institution is the best, a tool such as this will be incredibly powerful.

This project will approach the design of OSCAR by focusing its efforts on increasing its functionality and fixing current problems in the design. By the end of the semester, OSCAR will be ready for significant demonstrations of his abilities and the way will be paved for even more additions in the future.

40

Ongo-01: Team OSCAR

4.3 Appendices

4.3.1 Modular end product designThe end product has been designed in a modular fashion to promote a reduction in complexity. Internal systems have been grouped according to the functionalities they serve, and each system has been placed on a module, or “stage”. This allows each system to be removed from the others and developed independently, so that multiple tasks can be accomplished simultaneously. It also eases future modifications by allowing more modules to be stacked on top of the current design.

Figure 4.6 : Modular design of end product

A

Ongo-01: Team OSCAR

4.3.2 Milestone priority assignment methodTasks were first categorized by system, and then placed in a two-dimensional chart according to the urgency of each task and the amount of effort required for its completion (see Table 4.14, Table 4.15, Table 4.16, Table 4.17). A weighting system (see Table 4.18) was used to create a low-resolution contour map of task priorities.

The charts were then used to evaluate the relative priority of each task within each system, as shown in Table 4.19. Each task’s integer weight was divided by the sum of the integer weights of all tasks in that system, according to Eq. 4.1. The result was a percentage that determined a task’s priority relative to other tasks related to that system.

Eq. 4.1 : System priority algorithm

Each system was then assigned a priority scaling factor, representing the overall importance of its tasks within the entire project. Each task’s system-relative priority was multiplied by this scaling factor to obtain it project-relative priority, as shown in Eq. 4.2.

Eq. 4.2 : Project priority algorithm

The sum total of project-relative priorities was not equal to 100%, so the values of some of the priorities were forced. This brought the total project priority to 100%.

The tasks were then rearranged into a new chart (see Table 4.20) according to their milestone assignments. The internal sums of each milestone’s priorities were found, and these sums were taken as the project-relative priorities of each milestone.

B

Ongo-01: Team OSCAR

Table 4.14 : Priority grid for sensor system tasks

Total Weight Points: 39     Urgency    

Scaling Factor: 28% Highest High Medium Low Lowest

Sensors Highest Repair SONAR array

  High Characterize SONAR array

Develop navigation algorithm

Effort Medium

  Low

  Lowest

Table 4.15 : Priority grid for software system tasks

Total Weight Points:

39     Urgency    

Scaling Factor: 28% Highest High Medium Low Lowest

Software Highest Revise existing GUI software

Implement software to interact with

wheel tachometers

Automate software testing

  HighImplement

speech recognition

Effort MediumDesign software to interact with

wheel tachometers

Test newly developed software

Select I/O interface for end effector

  LowDocument newly

developed software

  LowestSelect speech

recognition software

C

Ongo-01: Team OSCAR

Table 4.16 : Priority grid for electromechanical system tasks

Total Weight Points:

56     Urgency    

Scaling Factor: 28% Highest High Medium Low Lowest

Emech Highest Implement new end effector

Design controller for end effector

motors

  HighDesign wheel tachometer

circuit

Test new end effector

Effort MediumImplement

wheel tachometer

circuit

Consider end effector

hardware solutions

Consider end effector control

solutions

Document end effector

controller

  LowConsider

purchase of DC/AC inverter

Install wheel tachometers

  LowestDocument wheel

tachometer circuit

Table 4.17 : Priority grid for general tasks

Total Weight Points:

35     Urgency    

Scaling Factor: 16% Highest High Medium Low Lowest

General Highest

  High Project Reporting

Present robot to campus visitors

(Urgency currently varies)

Effort Medium Develop scripts and macros

  Low

  Lowest

D

Ongo-01: Team OSCAR

Table 4.18 : Priority weight assignments by color code

Priority Weight (larger = greater priority) 9 8 7 6 5 4 3 2 1

Table 4.19 : Project priority assignment chart for tasks

TaskSystem priority

Project priority

Repair SONAR array 45% 11%Characterize SONAR array 30% 8%Develop navigation algorithm 25% 6%Implement speech recognition 16% 4%Revise existing GUI software 16% 4%Implement software to interact with wheel tachometers 14% 4%Automate software testing 12% 3%Design software to interact with wheel tachometers 12% 3%Select speech recognition software 10% 3%Test newly developed software 10% 3%Document newly developed software 6% 1%Select I/O interface for end effector 6% 1%Implement new end effector 15% 5%Design wheel tachometer circuit 12% 4%Design end effector controller 12% 4%Implement wheel tachometer circuit 12% 4%Consider end effector hardware solutions 10% 3%Consider end effector control solutions 8% 2%Consider purchase of DC/AC inverter 8% 2%Document end effector controller 7% 2%Install wheel tachometers 7% 1%Test new end effector 7% 1%Document wheel tachometer circuit 3% 1%Project reporting 39% 8%Present robot to campus visitors 33% 7%Develop scripts and macros 28% 5%

TOTAL   100%Yellow = percentage value forced for conformity to 100% total requirement

Table 4.20 : Project priority assignment chart for milestones

Milestone Project priority

E

Ongo-01: Team OSCAR

Technology Selection 11%Consider end effector hardware solutions 3%Select speech recognition software 3%Consider purchase of DC/AC inverter 2%Consider end effector control solutions 2%Select I/O interface for end effector 1%End Product Design 17%Develop navigation algorithm 6%Design wheel tachometer circuit 4%Design end effector controller 4%Design software to interact with wheel tachometers 3%End Product Implementation 33%Repair SONAR array 11%Implement new end effector 5%Implement wheel tachometer circuit 4%Implement software to interact with wheel tachometers 4%Implement speech recognition 4%Extend existing GUI software 4%Install wheel tachometers 1%End Product Testing 15%Characterize SONAR array 8%Test newly developed software 3%Automate software testing 3%Test new end effector 1%End product Documentation 4%Document end effector controller 2%Document wheel tachometer circuit 1%Document newly developed software 1%Project Reporting 8%Project plan 2%Poster 2%Status Report 2%IRP 2%End Product Demonstration 12%Present robot to campus visitors 7%Develop scripts and macros 5%

F

Ongo-01: Team OSCAR

4.3.3 Risk Assessment methodRisks were categorized both by cost of recovery and probability of occurrence, and then evaluated as the convergence of the two categories according to the assignment scheme shown in Table 4.22, which defines three categories of risk.

For example, a machining tragedy would be a devastating setback, but the likelihood of such an occurrence is extraordinarily low, and therefore it is assessed as a “Medium” risk overall. Conversely, the general failure of a piece of equipment would be somewhat easier to compensate than a machining tragedy, but is also significantly more likely to occur, and there is assessed as a “High” risk.

Table 4.21 : Risk level assignment chart

Risk Assessment Cost

Highest High Medium Low Lowest

Pro

babi

lity

Highest          

High   Equipment failure

Ordered parts do not arrive

on time 

Medium  Failure to complete

assigned tasks

Software testing shows bugs in code

   

Low Machining tragedy

Cost of development

exceeds expectations

   Failure to attend a meeting 

Lowest          

Table 4.22 : Risk assignments by color code

Risk Assignment High Medium Low

G

Ongo-01: Team OSCAR

4.3.4 Progress chart example

Milestone/Task Team Member Assigned Deadline % of Labor

CompleteTask

PriorityTotal Project Contribution Budget Spent Budget Allocation Total Budget

Expenditures

Current product documentation                

Task 1 Member 1 25-Jan 30% 9% 3% $ 20.00 $ 100.00 20% Task 2 Member 4 19-Feb 50% 4% 2% $ - $ 200.00 0%Technology selection                 Task Member 2 25-Jan 100% 15% 15% $ - $ 155.00 0%End product design                

Task Member 3 19-Feb 25% 6% 2% $ 450.00 $ 345.00 130%End product implementation                 Task Member 4 19-Feb 30% 4% 1% $ 50.00 $ 220.00 23%End product testing                 Task Member 5 19-Feb 30% 8% 2% $ 55.00 $ 400.00 14%End product documentation                 Task Member 1 3-Mar 35% 7% 2% $ 65.00 $ 500.00 13% Task Member 2 15-Mar 45% 3% 1% $ 75.00 $ 600.00 13%Project reporting                 Task Member 3 19-Feb 75% 5% 4% $ 80.00 $ 675.00 12%End product demonstration                 Task Member 5 25-Jan 80% 6% 5% $ 700.00 $ 750.00 93%Research                

Task Member 5 19-Feb 90% 9% 8% $ 900.00 $ 890.00 101%Total Project Completion         45%     50%

Figure 4.7 : Example project tracking chart

H

Ongo-01: Team OSCAR

4.3.5 Specifications for potential control solutionsThe following information was taken from documentation describing previous motor control solutions implemented into the end product. While these solutions are not currently in use, they could prove useful in developing a controller for the end effector assembly. The technologies discussed will be considered.

The old controller design required a discrete H-bridge controller rather than an integrated H-bridge controller such as the LT1158 Integrated Circuit. To build a high current H-bridge driver, four separate general-purpose high current MOSFET drivers were chosen for the application (Texas Instruments TDS2811). Each driver has a 2 A output drive capability.The MOSFET drivers require at least 8 to 9 volt trigger signal at the input terminals. The previous design used the LM629 IC, with only 2.5V output, is well below the minimum requirement of the new circuit. A HEX CMOS lever shifter was chosen to increase the voltage level due to ease of implementation and greater versatility over other options. The overall design is given in Figure 4.8.

Battery (12 V)

Direction

MOS Driver

in

out

MOS Driver

in

out

MOS Driver

in

out

Control Logic

Motor Load

MOS Driver

in

out

T3

Level Shifter

in2out1in1out2

7409

1

23

PWM Signal

7438

1

23

0

1 2

H-bridge

Figure 4.8 : NMOS H-Bridge Circuit Design Schematic

The original design of the new circuit used all NMOS transistors, causing the top two MOSFETS to dissipate a large amount of heat. The data in the proceeding section discusses the problems associated with the all NMOS design. After testing and revising the circuit, the circuit illustrated in Figure 4.9 was finally chosen.

A

Ongo-01: Team OSCAR

1 2

MOS Driver

in2out1in1out2

7409

1

23

NMOS

Motor Load

1 2

Control Logic

7409

1

23

PMOS

NMOS

0

H-bridge

Level Shifter

in2out1in1out2out3in3

in4 out4

7409

1

23

1 2

PWM Signal

Direction

MOS Driver

in2out1in1out2

1 2

PMOS

7409

1

23

Battery (12 V)

Figure 4.9 : PMOS/NMOS H-Bridge Circuit Design Schematic

This new circuit reduces the number MOSFET drivers from 4 to 2 since each MOSFET IC has two MOSFET drivers. The drivers also have built in input logic and only a HEX inverter IC need be added, and the level shifter has up to 6 level shifting inputs and outputs. The H-bridge was changed so that PMOS transistors drive the voltage high and NMOS transistors drive the voltage low. Only one NMOS/PMOS pair is on at one time. When the diagonal pair is switched to the opposite diagonal pair, the direction of the motor is changed. This allows for very efficient and fast direction control.

B

Ongo-01: Team OSCAR

Figure 4.10 : Specification for LM629 chip

C

Ongo-01: Team OSCAR

Figure 4.11 : Specification for LT1158 chip

D

Ongo-01: Team OSCAR

4.3.6 Optima D34/78 battery specifications

Battery Model: D34/78 Part Number: 8014-045 Nominal Voltage: 12 volts NSN: 6140 01 457 4341 Description: High power, dual purpose engine start

and deep-cycle, sealed lead acid battery

Physical Characteristics:

Plate Design: High purity lead-tin alloy. Wound cell configuration utilizing proprietary SPIRALCELL® technology.

Electrolyte: Sulfuric acid, H2SO4 Case: Polypropylene Color: Case: Light Gray

Cover: “OPTIMA“ Yellow Group Size: BCI: 34 Standard Metric Length: Width: Height: Weight:

10.” 6.875” 7.813” 43.5 lb.

254 mm 174.6 mm 198.4 mm (height at the top of the terminals) 19.8 kg

Terminal Configuration: SAE / BCI automotive and GM style side terminal (3/8” – 16 UNC – 2B, threaded nut).

Performance Data:

Open Circuit Voltage (fully charged): 13.1 volts

Internal Resistance (fully charged): 0.0028 ohms

Capacity: 55 Ah (C/20)

Reserve Capacity: BCI: 120 minutes

(25 amp discharge, 80°F (26.7°C), to 10.5 volts cut-off)

Power:

CCA (BCI 0°F): 750 amps MCA (BCI 32°F): 870 amps Recommended Charging:

The following charging methods are recommended to ensure a long battery life: (Always use a voltage regulated charger with voltage limits set as described below.)

Model: D34/78

E

Ongo-01: Team OSCAR

These batteries are designed for starting and deep cycling applications and for use in vehicles with large accessory loads. Recommended Charging Information: Alternator:

13.65 to 15.0 volts

Battery Charger (Constant Voltage): 13.8 to 15.0 volts; 10 amps maximum; 6-12 hours approximate

Float Charge: 13.2 to 13.8 volts; 1 amp maximum (indefinite time at lower voltages)

Rapid Recharge: (Constant voltage charger)

Maximum voltage 15.6 volts. No current limit as long as battery temperature remains below 125°F (51.7°C). Charge until current drops below 1 amp.

Cyclic or Series String Applications:

14.7 volts. No current limit as long as battery temperature remains below 125°F (51.7°C). When current falls below 1 amp, finish with 2 amp constant current for 1 hour. All limits must be strictly adhered to.

Recharge Time: (example assuming 100% discharge – 10.5 volts)

Current Approx. time to 90% charge 100 amps 50 amps 25 amps

35 minutes 75 minutes 140 minutes

Recharge time will vary according to temperature and charger characteristics. When using Constant Voltage chargers, amperage will taper down as the battery becomes recharged. When amperage drops below 1 amp, the battery will be close to a full state charge. (All charge recommendations assume an average room temperature of 77°F, 25°C) Always wear safety glasses when working with batteries. Always use a voltage regulated battery charger with limits set to the above ratings. Overcharging can cause the safety valves to open and battery gases to escape, causing premature end of life. These gases are flammable! You cannot replace water in sealed batteries that have been overcharged. Any battery that becomes very hot while charging should be disconnected immediately. Not fully charging a battery can result in poor performance and a reduction in capacity.

Shipping and Transportation Information: OPTIMA batteries can be shipped by AIR. The battery is nonspillable and is tested according to ICAO Technical Instructions DOC. 9284-AN/905 to meet the requirements of Packing Instructions No. 806 and is classified as non-regulated by IATA Special Provision A-48 and A-67 for UN2800. Terminals must be protected from short circuit.

F

Ongo-01: Team OSCAR

4.3.7 D-Link DWL-122 SpecificationsThe following specifications of the wireless ethernet units were taken from the product manufacturer’s website.

Table 4.23 : D-Link DWL-122 Specifications

Standards Antenna Type Frequency Range

IEEE 802.11b Omni-Directional Intregrated2.4GHz to 2.462GHz, ISM band

USB 1.1 Microstrip Antenna  Signal Rates Receiver Sensitivity Modulation Techniques11Mbps -81dBm for 11Mbps@ 8% PER Barker (1Mbps/0db)5.5Mbps (Packet Error Rate) Barker (2Mbps/3db)2Mbps -86dBm for 2Mbps@ 8% PER CCK (5.5Mbps/5.5db)1Mbps (Packet Error Rate) CCK (11Mbps/8.5db)Certifications Operating Voltage Transmit Output PowerFCC part 15b 5VDC +5% 16dBm (40mW)Modulation Temperature HumidityDirect Sequence Spread Spectrum

Operating: 32OF to 131OF (0OC to 55OC)

10% - 95% non-condensing, operating

11 - Chip Barker Sequence

Storing: 4OF to 167OF (-20OC to 75OC)

5% - 95% non-condensing, storage

Encryption Media Access Protocol Warranty64-, 128-bit WEP CSMA/CA with ACK 1 YearDimensions Supported Operating Systems RangeL=3.2 inches (82.5mm) Windows 2000 Up to 328 feet IndoorsW=1 inches (27.2mm) Windows XP  H=0.5 inches (12mm) Mac OS X (10.2x, 10.3.2)  

G

Ongo-01: Team OSCAR

4.3.8 Code SpecificationsThe following sections describe all Java and C# code written for the end product last semester. The reports were generated using Javadoc.4.3.8.1 Commjava.lang.Object Comm

public class Comm extends java.lang.Object

Launch the Command shell as a child and forward commands from stdin to the child's stdin after converting from the network protocol (detailed below) to the command set of Command. This layer exists only to isolate the network protocol from the actual command set, and to deal with various network comm issues such as timeouts. This class does not directly execute any commands for any part of the robot.

Commands are expected in the form of: COMMAND [ARG1] [ARG2] ... [ARGX] Where all arguments are optional, and any number of whitespace-separated arguments may exist with integer data. A few commands use the format: COMMAND [STRING] Where STRING is a required argument of any length, and any newlines in STRING are encoded as \n.

This class generates affirmative responses to commands in the form of: +COMMAND [ARG1] [ARG2] ... [ARGX] or in the case of commands that elicit a data response: +COMMAND [DATA1] [DATA2] ... [DATAX] Where COMMAND and all arguments match the incoming command. This provides and echo-like system to allow easy use of asynchronous commands. If a command is not recognized or cannot be executed a negative response is sent in the following form: -COMMAND [ARG1] [ARG2] ... [ARGX] or in the case of commands that elicit a data response: -COMMAND

The command set currently implemented follows:

NOOP [TIMEOUT] NOOP is always acknowledged affirmatively, and is provided only as a method to verify the integrity of the data link and as a "tickle" to keep the current command alive. If TIMEOUT is provided the comm timeout is set to TIMEOUT milliseconds. If no valid commands are received before the timeout expires, all motion is stopped. If TIMEOUT is 0 the comm timeout is disabled. The default comm timeout is 5000 milliseconds.

STOP

H

Ongo-01: Team OSCAR

STOP stops all movement of all parts of the robot. This includes the main drive system and any other moving parts.

EXIT EXIT stops all motion and commands Comm and its children to exit without calling the system halt command.

SHUTDOWN SHUTDOWN is used to halt the computer system in the robot. SHUTDOWN first stops all motion (like STOP) and then calls the system halt command.

SSPEAK [STRING] Speak the provided string.

SSTOP SSTOP immediately stops all current and pending speech.

RAW [STRING] Pass the provided string unmodified to the Command class. This command allows access to special-use commands and is always acknowledged affirmatively, even if the underlying command is not available.

MSTOP MSTOP stops all drive motion on the robot. It does not stop the motion of any other system.

MMOVE [FORWARD SPEED] [TURN SPEED] Activate the main drive system with FORWARD SPEED and TURN SPEED. Both arguments have a valid range of -127 to 127. See Motion.travel() for details.

MOUTPUT [OUTPUT] [ON] MOUTPUT activates and deactivates the accessory outputs of the motor controller. OUTPUT can be 0 or 1 and selects outputs C and D respectively, and ON is set to 1 to activate the output and 0 to deactivate it.

MSPEED MSPEED queries for the current drive wheel speeds. They are returned as integers on a scale from -127 to 127 in a message with the format: +MSPEED [MOTOR A] [MOTOR B]

MDIGITAL MDIGITAL queries for the state of the motor controller's digital inputs. Readings are returned in a message with the format: +MDIGITAL [INPUT E] [INPUT F] [E STOP INPUT]

MPOWER MPOWER queries for the power applied to each drive motor. Power readings are returned as integers on a scale from 0 to 127 in a message with the format: +MPOWER [MOTOR A] [MOTOR B]

MAMPS MAMPS queries for the power consumption of each drive motor. Readings are returned in integer amps from 0 to 255 in a message with the format: +MAMPS [MOTOR A] [MOTOR B]

MDISTANCE MDISTANCE queries for the estimated distance and vector of travel since the reset. All readings, including direction, are relative to the robot's initial position. Data is returned in a message with the format: +MDISTANCE [DISTANCE IN FEET] [DIRECTION IN

I

Ongo-01: Team OSCAR

DEGREES] The distance estimate can be reset by sending the command: MDISTANCE 0

Finally, this class may generate unsolicited messages in the format: ESTOP [STRING], where STRING is an unrecognized message sent from a lower layer of the robot's control structure. It is recommended that these messages be presented to the operator when received. No response is expected for ESTOP messages.

Author: Zach Kotlarek

Nested Class Summaryprivate class

Comm.CommTimeout           A simple watchdog implementation to shut down OSCAR if no commands are received before the timeout expires.

Private class

Comm.ForwardStderr           Forward all messages from our child’s stderr to our parent’s stderr.

Private class

Comm.InputMonitor           Monitor stdin and interpret incoming commands before forwarding them to stdout for processing by our child.

Private class

Comm.OutputMonitor           Monitor our child’s stdout and interpret incoming commands before forwarding them to stdout for processing by our parent.

 

Field Summaryprivate

java.io.BufferedReaderchildErr            

private java.io.PrintStream

childIn            

private java.io.BufferedReader

childOut            

private java.lang.Process

command            

private static java.lang.Strin

g

commandExecutable            

private static long defaultCommTimeout            

J

Ongo-01: Team OSCAR

private Comm.ForwardStderr

err            

private java.io.PrintStream

errOut            

private java.lang.Thread

errThread            

private java.lang.Thread

inputThread            

private Comm.InputMonitor

ins            

private java.lang.Thread

outputThread            

private Comm.OutputMonitor

outs            

private java.lang.Runtime

run            

private java.lang.Thread

shutdown            

private  boolean stopping            

private java.io.BufferedReader

sysIn            

private java.io.PrintStream

sysOut            

private Comm.CommTimeout

watcher            

private java.lang.Thread

watcherThread            

Constructor SummaryComm()           Generic contructor.

Method Summary

K

Ongo-01: Team OSCAR

private java.io.BufferedReader

getBufferedReader(java.io.InputStream input)           Create a BufferedReader from an InputStream.

Private java.io.PrintStream

getPrintStream(java.io.OutputStream output)           Create a PrintStream from an OutputStream.

Static void main(java.lang.String[] args)           Launch the Command shell as a child and begin interpreting commands for it.

Private java.lang.String

parseCommand(java.lang.String str)           Returns the first word from a whitespace-separated list of words.

Private  int[] parseInts(java.lang.String str)           Returns an array of ints from a list of whitespace-separated ints.

Private java.lang.String

parseString(java.lang.String str)           Returns all but the first word from a whitespace-separated list of words.

 Void run()           Fire off Command as our child, capture the appropriate I/O streams, and start a thread to monitor each one.

Private  void setAllDone()           Signal all threads to exit, then wait for them to join.

Private  void stopAllMotion()           Called on STOP, or whenever all motion should be stopped.

4.3.8.2 Commandjava.lang.Object Command

public class Command extends java.lang.Object

Command is the lowest-level class for OSCAR that provides a direct user interface. Command is also the lowest-level class that has a complete picture of the state of the robot, as all lower classes control only certain sub-systems of the robot.

At this point, Command controls on speech and drive motion, making Command reasonably simply. As the hardware progresses though, Command will likely host feedback logic for autonomous control, which would make it significantly more complicated. Luckily that's not my problem.

Author: Zachary Kotlarek

L

Ongo-01: Team OSCAR

Field Summaryprivate  boolean done

           private

static java.lang.String

haltExecutable            

private java.io.BufferedReader

ins            

private  MotionCommand motion            

private java.lang.Thread

motionThread            

private static java.lang.Strin

g

mPort            

private java.io.PrintStream

outs            

private java.lang.Runtime

run            

private java.lang.Thread

shutdown            

private  Speech speech            

private static java.lang.Strin

g

sPort            

 

Constructor SummaryCommand()           Generic Constructor.

 

Method Summaryprivate

java.io.BufferedReadergetBufferedReader(java.io.InputStream input)           Create a BufferedReader from an InputStream.

static void main(java.lang.String[] args)

M

Ongo-01: Team OSCAR

          Listen for and execute commands.private

java.lang.StringparseCommand(java.lang.String str)           Returns the first word from a whitespace-separated list of words.

private  int[] parseInts(java.lang.String str)           Returns an array of ints from a list of whitespace-separated ints.

private java.lang.String

parseString(java.lang.String str)           Returns all but the first word from a whitespace-separated list of words.

 void run()           Set up our control threads and process commands.

private  void runCommand()            

 void setAllDone()           Signal all threads to exit, then wait for them to re-join.

private java.lang.String

waitInput(java.io.BufferedReader input)           Wait for input on a BufferedReader.

4.3.8.3 Motionjava.lang.Object Motion

public class Motion extends java.lang.Object

This class provides low-level support for motion control, and a general interface to various features of the motor controller. It is intended to be used in a higher-level class that deals with things like duration of travel.

Author: Zachary Kotlarek

Field Summaryprivate

intcontrolMode            

private static long

defaultTimeout            

private Serial

sp            

N

Ongo-01: Team OSCAR

private long

timeout            

 

Constructor SummaryMotion(java.lang.String portPath)           Constructor.

 

Method Summary void closePort()

          Close the serial port for this class, if it has been opened. int getAcceleration()

          Read the current motor control mode setting. int getControlMode()

          Read the current motor control mode setting.private

java.lang.StringgetParameter(int paramNum)           Query the motor controller for the value of the specified parameter.

private  void go(int speedA, int speedB)           Command motor channel A to speedA and motor channel B to speedB.

 java.lang.String readAmps()           Read the amp consumption readings from the motor controller.

 java.lang.String readAnalog()           Read the analog inputs from the motor controller.

 java.lang.String readDigital()           Read the digital inputs from the motor controller.

 java.lang.String readPower()           Read the current power settings from the motor controller.

 void setAcceleration(int acc)           Set the acceleration rate to one of the 6 rates built in to the motor controller.

 void setControlMode(boolean on, boolean closed)           Set the motor controller mode as specified.

 void setEstop(boolean enabled)           Enable or disable the eStop button.

O

Ongo-01: Team OSCAR

 void setOutput(int output, boolean on)           Enable or disable the specified motor controller output, as indicated by the 'on' parameter.

private  void setParameter(int paramNum, int paramValue)           Set the specified parameter to the specified value, and reset the motor controller so the change takes effect.

 void setWatchdog(boolean on)           Turn watchdog mode on or off, as specified.

 void stop()           Immediately sends a stop command to both motor channels, if the serial port has been initialized.

 void travel(int forwardSpeed, int turnSpeed)           Travel, driving and turning at the specified speeds.

P

Ongo-01: Team OSCAR

4.3.8.4 MotionCommandjava.lang.Object MotionCommandAll Implemented Interfaces:

java.lang.Runnable

public class MotionCommand extends java.lang.Object implements java.lang.Runnable

Provide a single-entry queuing mechanism for the Motion class to facilitate a simple interface with the main Command class.

This class also provides a Runnable wrapper for the Motion class, and provides the accumulation facilties for estimating distance and direction by motor speed.

This class understands the following messages. All other commands are silently ignored:

STOP Stop all drive motion

MOVE X Y Move with forward speed X and turn speed Y (See Motion.travel())

OUTPUT X Y Set accessory output X (0 = C, 1 = D) to Y (0 = off, 1 = on)

RESET_DISTANCE Reset the distance and direction estimate

There are many parameters available on the RoboteQ motor controller, but they are either of no interest in our choosen control mode, or should not be available for change at runtime for safety purposes. As such this class provides no access to set or read those parameters. At initialization however, this class sets the following parameters:

Active Emergency Stop Slow Acceleration Watchdog Comm Mode Mixed Steering Mode Open-Loop Control Mode

Author: Zachary Kotlarek

Field Summaryprivate  int argX

           

Q

Ongo-01: Team OSCAR

private  int argY            

private java.lang.String

command            

private static long

defaultMinCommandPeriod            

private static long

defaultSendPeriod            

private  boolean done            

private  long lastUpdate            

private  long minCommandPeriod            

private  Motion motion            

 MotionReader reader            

private  long sendPeriod            

private java.lang.Thread

t            

private java.lang.String

verb            

 

Constructor SummaryMotionCommand(java.lang.String port)           Constuctor.

 

Method Summary void newCommand(java.lang.String newCommand)

          Accept a new command for processing, if and only if at least minCommandPeriod has elapsed since the last command was accepted.

 void run()

R

Ongo-01: Team OSCAR

          Continously run the last valid command.private

voidrunCommand()           Send the last accepted command to the motor controller, via the Motion class.

 void setDone()           Stop the listening loop and allow it to exit cleanly.

private void

splitCommand()           Parse the incoming command string into a verb and up to two integer arguments.

4.3.8.5 MotionReaderjava.lang.Object MotionReaderAll Implemented Interfaces:

java.lang.Runnable

public class MotionReader extends java.lang.Object implements java.lang.Runnable

Monitor all available motor controller variables asynchronously. This potentially increases latency, but it allows direct access to the previously read values, rather than requiring a new query for each request, which in turn reduces serial bandwidth use.

To prevent error propagation, this class implements a simple data expiration system, which invalidates caches readings after 1000 milliseconds.

Author: Zachary Kotlarek

Field Summaryprivate int[]

amps            

private long

ampsUpdate            

private int[]

analog            

private long

analogUpdate            

private int

angle            

private defaultPollInterval

S

Ongo-01: Team OSCAR

static long            private

static longdefaultPollTimeout            

private int[]

digital            

private long

digitalUpdate            

private int

distance            

private long

distanceUpdate            

private boolean

done            

private int

index            

private Motion

motion            

private static int

numParams            

private long

pollInterval            

private long

pollTimeout            

private int[]

power            

private long

powerUpdate            

private static int

speedScaler            

 

Constructor SummaryMotionReader(Motion mot)           Generic constructor.

 

T

Ongo-01: Team OSCAR

Method Summary int getAmps(int x)

          Get the amp consumption reading for channel X from the motor controller. int getAnalog(int x)

          Get the state of analog input X of the motor controller. int getAngle()

          Get the estimated angle of travel based on motor speed and direction since the last call to resetDistance().

 int getDigital(int x)           Get the state of digital input X of the motor controller.

 int getDistance()           Get the estimated distance traveled based on motor speed and direction since the last call to resetDistance().

 int getPower(int x)           Get the current power setting for channel X from the motor controller.

private void

looper()           Read the next set of variables from the motor controller.

 void resetDistance()           Reset the counter for estimated distance traveled.

 void run()           Continously poll for new input.

private void

setAmps(int ampsA, int ampsB)           Update the stored amps readings

private void

setAnalog(int ana1, int ana2)           Update the stored analog input readings

private void

setDigital(int digi1, int digi2, int digi3)           Update the stored digital input readings

private void

setDistance(int dist, int ang)           Update the stored estimated distance

 void setDone()           Stop the polling loop and allow it to exit cleanly.

private void

setPower(int powerA, int powerB)           Update the stored power readings

private int[]

splitInts(java.lang.String str)           Returns an array of ints from a list of comma-separated ints.

private void

updateIndex()           Update the index for looper, or any other method that might be interested.

U

Ongo-01: Team OSCAR

4.3.8.6 Networkjava.lang.Object Network

public class Network extends java.lang.Object

Forward data between a network socket and a local program. This class is intended for use with OSCAR Comm, but really could be used to provide a network interface for anything that passes newline-separated data on stdin and stdout.

This class logs messages from the child's stderr by default and can log in-band data in either of both directions. Logging options are configurable at runtime via command-line flags.

This class optionally provides network timeout support via SO_timeouts. The default timeout is 30 seconds, and is configurable only at compile time. You'll probably want timeouts of some sort though, because the network server is not multi-threaded, and will run until the child exits.

Author: Zachary Kotlarek

Nested Class Summaryprivate class

Network.ForwardStderr           Forward all messages from our child's stderr to our parent's stderr.

private class

Network.InputMonitor           Monitor stdin and interpret incoming commands before forwarding them to stdout for processing by our child.

private class

Network.LoggerMonitor           Launch, and as necessary, re-launch the "logger" program to provide access to the syslog facility.

private class

Network.OutputMonitor           Monitor our child's stdout and forward it to the network-connected client, logging if requested.

 

Field Summaryprivate

java.io.InputStreamchildErr            

private java.io.PrintStream

childIn            

V

Ongo-01: Team OSCAR

private java.io.InputStream

childOut            

private java.lang.Process

comm            

private static java.lang.Strin

g

commExecutable            

private Network.ForwardStderr

err            

private static java.lang.Strin

g

errLogTag            

private java.lang.Thread

errThread            

private static java.lang.Strin

g

inputLogTag            

private java.lang.Thread

inputThread            

private Network.InputMonitor

ins            

private  boolean logErr            

private java.lang.Process

logger            

private static java.lang.Strin

g

loggerExecutable            

private java.lang.Thread

loggerThread            

private  boolean logInput            

private  boolean logOutput            

private Network.LoggerMonitor

logs            

private java.io.InputStream

netIn            

private java.io.PrintStream

netOut            

private outputLogTag

W

Ongo-01: Team OSCAR

static java.lang.String            

private java.lang.Thread

outputThread            

private Network.OutputMonitor

outs            

private static int port            

private java.lang.Runtime

run            

private java.lang.Thread

shutdown            

private java.net.Socket

socks            

private  boolean stopping            

private static int tcpTimout            

 

Constructor SummaryNetwork()           Generic constructor.

 

Method Summaryprivate

java.io.PrintStreamgetPrintStream(java.io.OutputStream output)           Create a PrintStream from an OutputStream.

static void main(java.lang.String[] args)           Launch the Comm shell as a child and begin forwarding commands to and from it.

private java.lang.String

readLine(java.io.InputStream ins)           Much like the method of the BufferedReader class, this method waits on an input stream until an entire line is available, then returns that line without the newline.

 void run()           Run for each new connection.

X

Ongo-01: Team OSCAR

private  void setAllDone()           Signal all threads to exit, then wait for them to join.

4.3.8.7 Sensorsjava.lang.Object Sensors

public class Sensors extends java.lang.Object

A generic interface to the sensor ring. As of revision 1.8 this class provides only basic test functionality.

Author: Zachary Kotlarek

Y

Ongo-01: Team OSCAR

Field Summary Serial sp

           

 

Constructor SummarySensors(java.lang.String portPath)           Generic constructor.

 

Method Summary void go()

          Send a command, wait for a reply, print both to the screen.static void main(java.lang.String[] args)

          A simple main to allow for easy sensor testing. java.lang.String toString(java.lang.String inString)

          Return the input string as a space-seperated list of its byte-wise components, in hex.

4.3.8.8 Serialjava.lang.Object SerialAll Implemented Interfaces:

java.util.EventListener, javax.comm.SerialPortEventListener

public class Serial extends java.lang.Object implements javax.comm.SerialPortEventListener

A basic framework for finding and initialzing serial ports, and creating input and output streams for the same. This class does not have a complex serial port event handler, but could be extended if one was necessary.

This class implments keyed, re-entrant locking. Java provides sufficient structure for keyless re-entrant locks, but given the overall software design keyed locks were easier to implement and more reliable. This class does not require locks to be used externally, but does attempt to aquire a lock before writting, and therefore can be safely used in systems that mix locking and non-locking methods.

Z

Ongo-01: Team OSCAR

This class assumes that serial initialization errors, should be fatal. For OSCAR's motion control and sensors this is acceptable. If this class is ever used for something else though, it may be desirable to replace the System.exit() calls with something less drastic.

Author: Zachary Kotlarek

Field Summaryprivate  int baudRate

           private  int dataBits

           private static long defaultLockTimeout

           private

java.io.InputStreamins            

private  int[] keys            

private java.lang.String

lastInput            

private  long lockTimeout            

private static int maxLocks            

private  boolean newInput            

private  int numLocks            

private java.io.OutputStream

outs            

private  int parity            

private  boolean portUp            

private java.util.Random

rand            

private javax.comm.SerialPort

sp            

private  int stopBits

AA

Ongo-01: Team OSCAR

           

 

Constructor SummarySerial()           Generic constructor.Serial(java.lang.String portPath)           Constructor.Serial(java.lang.String portPath, boolean sensors)           Constuctor.Serial(java.lang.String portPath, int baud, int data, int stop, int par)           Constuctor.

 

Method Summary boolean checkInput()

          This function returns true if there is new, unread input available. void closePort()

          Closes the serial port, if it has been initialized.private  void constructor(java.lang.String portPath, int baud, int data,

int stop, int par)           Our real constructor, to consolidate code from the four wrappers above.

 java.lang.String getSerialPorts()           Retuns a list of serial port names, as java sees them.

 void initPort(java.lang.String portPath)           Initializes the specified serial port for reading and writing and installs a simple event handler for the port.

 boolean isOpen()           Returns true if the serial port has been initialized.

 int lock(long timeout)           A simple wrapper for the lock(int, int) method.

 int lock(long timeout, int key)           Set another level of serial transaction lock.

 java.lang.String read()           Returns new input from the serial port, if available.

BB

Ongo-01: Team OSCAR

 void serialEvent(javax.comm.SerialPortEvent event)           This method is called when a serial event is detected by the JRE.

 void setCommParams(int baud, int data, int stop, int par)           Set or reset the comm parameters on the serial port, if open.

private  void setCommParamsDefault()           Set the comm parameters to their previously stored value.

 boolean unlock(int key)           Remove a level of serial transaction lock, if the key matches.

 java.lang.String waitRead(long timeout)           Wait up to the specified number of milliseconds for new input.

 void write(java.lang.String str)           A simple wrapper for the write(String, int) method.

 void write(java.lang.String str, int key)           Write the specified string, if the serial port has been initialized.

4.3.8.9 Speechjava.lang.Object SpeechAll Implemented Interfaces:

java.lang.Runnable

public class Speech extends java.lang.Object implements java.lang.Runnable

Speech initializes the FreeTTS text-to-speech engine and provides methods for speaking a arbitrary strings, optionally blocking while speaking.

Author: jasolson@iastate.edu Modified by David H, Oct 17, 2004 Async. support added by Zachary Kotlarek

Field Summaryprivate  boolean isLoaded

           private

javax.speech.synthesis.Synthesizersynthesizer            

 

CC

Ongo-01: Team OSCAR

Constructor SummarySpeech()           Constructor, no arguments.Speech(boolean async)           Constructor.

 

Method Summary void asyncSpeak(java.lang.String toSpeak)

          Speak the specified text, waiting for the speech system to initialize if necessary.

 void blockUntilReady()           This method simply blocks until speech is complete.

 boolean isLoaded()           Returns true if the synth is currently loaded.

 void run()           Creates the speech synthesizer.

 void speak(java.lang.String toSpeak)           Speak the specified text, if the speech system has been initialized.

 void stop()           Cancel all current and pending speech items.

 void unload()           Stops speech and unloads the synth.

DD

Ongo-01: Team OSCAR

4.3.8.10 OscarGUIpublic class OscarGUI

Implements the GUI control for OSCAR. It will take input from the user and send simple text commands to OSCAR using a standard socket.

Author: David Hawley davidhw@iastate.edu

Method SummarymenuRecordScript_Click Starts recording UI actions to make a scriptmenuNormal_Click  Disables the visibility of the advanced viewmenuAdvanced_Click Makes the advanced view visiblemenuPlayScript_Click Opens a dialog box to select a script then starts playing itmenuConnect_Click  Connects to OSCARmenuDisconect_Click Disconnects from OSCARmenuPowerOff_Click Commands OSCAR to power downmenuExit_Click Disconnects from OSCAR and exits the programvsbSpeed_Scroll Changes the forward/backward speed of OSCARhsbTurnSpeed_Scroll Changes the turn speed of OSCARbtnForward_Click Causes OSCAR to move forwardbtnBack_Click Causes OSCAR to move backwardbtnLeft_Click Causes OSCAR to turn leftbtnRight_Click Causes OSCAR to turn rightbtnStop_Click Causes OSCAR to stopbtnSayIt_Click Makes OSCAR say the text that is currently in txtSayItbtnRecordScript_Click Starts recording UI actions to make a scriptbtnPlayScript_Click Starts recording UI actions to make a scriptbtnSendCommand_Click Sends a manually entered to command to OSCARs command processor

EE

Ongo-01: Team OSCAR

4.3.9 Software interface diagram

Figure 4.12 : Software interface diagram

FF

Ongo-01: Team OSCAR

4.3.10ScreenshotsThe following are some screenshots from the remote control program.

4.3.10.1 GUI ScreenshotsThe client GUI for the robot is shown below. The GUI provides a user friendly way to command the robot and receive feedback about the robot’s status.

Figure 4.13 : Normal mode layout

4.3.10.2 Main WindowFigure 4.13 is a screenshot is of the main window in normal mode. Functionality is divided into four main sections: Movement Controls, Speech, Sensor Display, and Scripts. The Movement Controls section provides the basic functionality to move forward, backward, left and right as well as control movement speed and turn speed; the Speech section allows the user to enter a string of text and then command the robot to say it; and the Sensor display section simply displays the current readings from each transducer in the robot’s array. The Scripts section is provided to easily record a series of commands for playback later.

GG

Ongo-01: Team OSCAR

Figure 4.14 : Advanced mode layout

Figure 4.14 depicts the main window in advanced mode. When the GUI is in advanced mode, all network traffic is shown as a log. The user is also able to type in a manual command and send it directly to the robot.

HH

Ongo-01: Team OSCAR

4.3.10.3 Drop-down menusThe following screenshots (Figures Figure 4.15, Figure 4.16, and Figure 4.17) show the menu system. The File menu allows the user to perform basic commands such as establishing a connection with the robot, commanding the robot to power down, and exiting the program; the Script menu allows the user to start recording a new script or play back an existing script; and the View menu allows the user to switch between the advanced and normal modes of the main window.

Figure 4.15 : File menu

Figure 4.16 : Script menu

Figure 4.17 : View menu

II