Ongo01: Project OSCAR

Fall 2004 Status ReportClient:

Iowa State University,Department of Electrical and Computer Engineering

Faculty Advisor:Prof. Ralph E. Patterson III

Team Members:

Gustavo Aramayo ME 466David Hawley Cpr E 491William Hoang Cpr E 491Zachary Kotlarek Cpr E 491Michael Larson EE 491Dung Nguyen EE 492Huy Nguyen EE 492Justin Rasmussen Cpr E 491Gavin Ripley Cpr E 491David Staab EE 492Jason Sytsma EE 491John Walvatne ME 466

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.

12 Nov 2004

Table of ContentsList of Figures...................................................................................................................................iList of Tables...................................................................................................................................iiList of Tables...................................................................................................................................iiList of Symbols..............................................................................................................................iiiList of Symbols..............................................................................................................................iiiList of Definitions...........................................................................................................................iv1 Introductory Materials.............................................................................................................1

1.1 Executive Summary.........................................................................................................11.1.1 Need For The Project...............................................................................................11.1.2 The Project...............................................................................................................11.1.3 Current Results........................................................................................................11.1.4 Current Accomplishments.......................................................................................11.1.5 Work To Be Completed...........................................................................................2

1.2 Problem Statement...........................................................................................................21.2.1 General Problem Statement.....................................................................................21.2.2 General Solution Approach.....................................................................................3

1.3 Operating Environment...................................................................................................31.4 Intended Users and Intended Uses...................................................................................3

1.4.1 Intended Users.........................................................................................................31.4.2 Intended Uses...........................................................................................................3

1.5 Assumptions and Limitations..........................................................................................41.5.1 Assumptions............................................................................................................41.5.2 Limitations...............................................................................................................4

1.6 Expected End Product and Other Deliverables...............................................................42 Project Accomplishments and Current Status.........................................................................5

2.1 Previous accomplishments...............................................................................................52.2 Present accomplishments.................................................................................................72.3 Required future activities...............................................................................................102.4 Current project and end product status..........................................................................12

2.4.1 Computer System...................................................................................................122.4.1.1 Hardware............................................................................................................122.4.1.2 Software.............................................................................................................13

2.4.1.2.1 Documentation of Code...............................................................................132.4.1.2.2 Control Infrastructure..................................................................................132.4.1.2.3 Remote Interface..........................................................................................14

GUI Screenshots................................................................................................................152.4.1.2.4 Main Window..............................................................................................152.4.1.2.5 Drop-down menus.......................................................................................16

2.4.2 Sensor System........................................................................................................172.4.2.1 Research.............................................................................................................172.4.2.2 Current Status....................................................................................................17

2.4.3 Electromechanical System.....................................................................................182.4.3.1 Power System....................................................................................................182.4.3.2 End Effector.......................................................................................................222.4.3.3 Drive System.....................................................................................................26

i

2.5 Recommendation for continued effort...........................................................................273 Documentation of current efforts and results........................................................................29

3.1 Project definition activities............................................................................................293.2 Research activities.........................................................................................................31

3.2.1 Optical encoder interface.......................................................................................313.2.2 Navigation algorithm.............................................................................................31

3.2.2.1 SONAR..............................................................................................................313.2.2.2 Limitation of Space............................................................................................33

3.3 Design activities.............................................................................................................333.3.1 End effector design................................................................................................333.3.2 Implementation activities.......................................................................................36

3.4 Testing and modification activities................................................................................363.4.1 End effector testing................................................................................................363.4.2 SONAR Testing.....................................................................................................36

3.5 Resources and Schedules...............................................................................................383.5.1 Resource requirements...........................................................................................38

3.5.1.1 Personnel effort requirements............................................................................383.5.1.1.1 Estimated Requirements..............................................................................393.5.1.1.2 Actual Requirements (to date).....................................................................41

3.5.1.2 Financial requirements.......................................................................................423.5.1.2.1 Estimated Requirements..............................................................................433.5.1.2.2 Actual Requirements (to date).....................................................................44

3.5.2 Schedules...............................................................................................................453.5.2.1 Project schedule.................................................................................................453.5.2.2 Deliverable schedule..........................................................................................48

4 Closure Materials...................................................................................................................494.1 Lessons Learned............................................................................................................49

4.1.1 What went well......................................................................................................494.1.2 What did not go well..............................................................................................494.1.3 What technical knowledge was gained..................................................................504.1.4 What non-technical knowledge was gained..........................................................504.1.5 What would be done differently if you could do it over again..............................50

4.2 Risk and Risk Management...........................................................................................504.2.1 Anticipated potential risks and their management.................................................51

4.2.1.1 High-Level Risks...............................................................................................514.2.1.1.1 Ordered parts do not arrive on time.............................................................514.2.1.1.2 Equipment failure........................................................................................51

4.2.1.2 Medium-Level Risks.........................................................................................514.2.1.2.1 Failure to complete assigned tasks..............................................................514.2.1.2.2 Cost of development exceeds expectations.................................................514.2.1.2.3 Machining tragedy.......................................................................................51

4.2.1.3 Low-Level Risks................................................................................................524.2.1.3.1 Failure to attend a meeting..........................................................................524.2.1.3.2 Software testing shows bugs in code...........................................................52

4.2.2 Anticipated risks encountered and success in their management..........................524.2.2.1 Equipment failure..............................................................................................52

ii

4.2.2.2 Software testing shows bugs in code.................................................................524.2.2.3 Failure to attend a meeting................................................................................52

4.2.3 Unanticipated risks encountered and attempts to manage them............................534.2.3.1 Failure of the sensor system..............................................................................534.2.3.2 Wheel tachometers do not use expected interface.............................................53

4.2.4 Resultant changes in risk management because of unanticipated risks.................534.3 Project Team Information..............................................................................................53

4.3.1 Client information..................................................................................................544.3.2 Faculty advisor information...................................................................................544.3.3 Student team information......................................................................................54

4.4 Closing summary...........................................................................................................574.5 References......................................................................................................................584.6 Appendices......................................................................................................................A

4.6.1 Power System User’s Manual.................................................................................A4.6.2 Optima D34/78 battery specifications....................................................................D4.6.3 Selected specifications of RoboteQ AX2500 motor controller...............................F4.6.4 US Digital S1-256-B optical encoder specifications..............................................G4.6.5 D-Link DWL-122 Specifications.............................................................................I4.6.6 SONAR array schematics........................................................................................J

4.6.6.1 6500-series ranging module.................................................................................J4.6.6.2 BX-24 microcontroller........................................................................................K

4.6.7 Documentation of code...........................................................................................L4.6.7.1 Comm..................................................................................................................L4.6.7.2 Command............................................................................................................P4.6.7.3 Motion.................................................................................................................R4.6.7.4 MotionCommand................................................................................................T4.6.7.5 MotionReader.....................................................................................................V4.6.7.6 Network..............................................................................................................X4.6.7.7 Sensors.............................................................................................................AA4.6.7.8 Serial.................................................................................................................BB4.6.7.9 Speech...............................................................................................................EE4.6.7.10 OscarGUI.....................................................................................................GG

iii

List of FiguresFigure 2.1 : Software interface diagram........................................................................................14Figure 2.2 : Normal mode layout...................................................................................................15Figure 2.3 : Advanced mode layout...............................................................................................16Figure 2.4 : File menu....................................................................................................................17Figure 2.5 : Script menu................................................................................................................17Figure 2.6 : View menu.................................................................................................................17Figure 2.7 : Photographs of power system implementation..........................................................19Figure 2.8 : Power system schematic............................................................................................20Figure 2.9 : Modified battery charger............................................................................................21Figure 2.10 : Cycle length of Optima D34/78 battery...................................................................22Figure 2.11 : Gripper assembly.....................................................................................................23Figure 2.12 : Wrist assembly.........................................................................................................23Figure 2.13 : Forearm assembly....................................................................................................23Figure 2.14 : Upper arm assembly.................................................................................................23Figure 2.15 : Fully assembled arm................................................................................................23Figure 2.16 : Base assembly..........................................................................................................23Figure 2.17 : Fully assembled end effector...................................................................................24Figure 2.18 : Drivetrain physical components...............................................................................27Figure 2.19 : Drivetrain motor controller......................................................................................27Figure 3.1 : OSCAR in a hallway..................................................................................................32Figure 3.2 : OSCAR in limited space............................................................................................33Figure 3.3 : COSMOSWork Analysis of forearm under loading..................................................35Figure 3.4 : Circuit used for testing ranging modules...................................................................37Figure 3.5 : Signals used in testing sensor array...........................................................................37Figure 3.6 : Actual project schedule 1...........................................................................................46Figure 3.7 : Actual project schedule 2...........................................................................................47Figure 3.8 : Deliverable schedule..................................................................................................48Figure 4.1 : Power interface panel 1...............................................................................................AFigure 4.3 : Power interface panel 3...............................................................................................BFigure 4.4 : RoboteQ serial pin locations........................................................................................FFigure 4.5 : RoboteQ serial connection wiring diagram.................................................................FFigure 4.6 : RoboteQ serial signal-to-pin assignments...................................................................FFigure 4.7 : US Digital S1 optical encoder.....................................................................................GFigure 4.8 : Mechanical drawing of US Digital S1 optical encoder...............................................GFigure 4.9 : 6500-series ranging module schematic.........................................................................JFigure 4.10 : BX-24 microcontroller schematic.............................................................................K

i

List of TablesTable 2.1 : SONAR array replacement component s....................................................................11Table 2.2 : End effector motion.....................................................................................................24Table 2.3 : Physical dimensions of the end effector......................................................................25Table 2.4 : Weight of components in gripper................................................................................26Table 2.5 : Weight of components in forearm...............................................................................26Table 2.6 : Weight of components in wrist....................................................................................26Table 2.7 : Weight of components in upper arm...........................................................................26Table 2.8 : Weight of components in base....................................................................................26Table 2.9 : Total weight of assembled components......................................................................26Table 3.1 : Old Milestones from Fall 2004 Project Plan...............................................................29Table 3.2 : New Milestones...........................................................................................................29Table 3.3 : New Milestone task assignments.................................................................................30Table 3.4 : Drivetrain motor specifications...................................................................................34Table 3.5 : Calculations for claw motor specification...................................................................34Table 3.6 : Calculations for wrist motor specification..................................................................34Table 3.7 : Calculations for elbow motor specification.................................................................35Table 3.8 : Task description reference chart..................................................................................39Table 3.9 : Estimated personnel requirement 1.............................................................................40Table 3.10 : Estimated personnel requirement 2...........................................................................40Table 3.11 : Actual personnel requirement 1.................................................................................41Table 3.12 : Actual personnel requirement 2.................................................................................41Table 3.13 : Additional personnel requirements............................................................................42Table 3.14 : Estimated financial requirements..............................................................................43Table 3.15 : Actual financial requirements....................................................................................44Table 4.1 : Optical encoder mechanical specifications...................................................................HTable 4.2 : Optical encoder mounting specifications.....................................................................HTable 4.3 : Optical encoder electrical pin-out.................................................................................HTable 4.4 : D-Link DWL-122 Specifications...................................................................................I

ii

List of Symbolso Degrees

® Trademark restriction applies

§ Section reference

iii

List of Definitions AC Alternating current

CAD Computer-aided design (software)

CCD Computer-controlled display

composite bushing A self-lubricating linear bearing lined with plastic

COSMOSWorks Finite element analysis software by the SolidWorks Corporation

CVS Concurrent versions system

CyBot The robotic predecessor to OSCAR.

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

end effector The assembly of electrically-controlled mechanical arm and gripper

ethernet A widely-used computer network communication protocol

GUI Graphical user interface

Javadoc A code-commenting system designed by Sun Microsystems®

linear bearing A rolling element that moves on a straight track

runout Movement from side to side

SAE Society of Automotive Engineers

servo motor Electric motor used to control components

Solidworks® A CAD program developed by the Solidworks Corporation

SONAR Sound navigation and ranging

tachometer A device for indicating speed of rotation from the wheels

troubleshoot Assess and amend problems that arise during the engineering process

iv

1 Introductory MaterialsThe following section provides an executive summary of this status report, serves as an introduction to Project OSCAR, and details the goals and end product expected from this project.

1.1 Executive SummaryThe following section provides a summary of the project, laying out both its current status and expected results.

1.1.1 Need For The ProjectEver since the development of CyBot, Iowa State’s first interactive robot, the university and its visitors have expressed interest in students’ abilities to design and implement robots; however, several factors, such as size and weight, prevented CyBot from achieving its goals as a demonstration too. In an attempt to overcome such liabilities, Project OSCAR was proposed, and the possibility for additional functionalities has grown with the passing of every semester. It is important that Iowa State has an entertaining approach to help generate interest in not only their engineering department, but engineering in general. When a project like this can influence a person’s career choice, it can only result in the addition of new talent and ideas to the engineering industry.

1.1.2 The ProjectThe Octagonal Speech-Controlled Autonomous Robot (OSCAR) is on its eighth semester as an ongoing project at Iowa State University. It was designed to demonstrate the integration of multiple technologies of electrical, computer and mechanical engineering. The multi-layered robot consists of a two belt-driven wheels, a sensory array to detect its surroundings, and an onboard computer to interact with the previous two components. A robotic arm, or end effector, will be installed in the future. Currently, the main application of the project is to let visitors of all ages interact with the robot to help promote the engineering field. Each semester, an OSCAR team has the responsibility to improve upon and add functionality to the robot.

1.1.3 Current ResultsMuch has been accomplished on the robot since its original development in the Spring 2001 semester. Initial work focused on programming the motion controller and connection board for the SONAR. Software was then written to properly interpret the data received from these two devices. An arm assembly with a gripper was designed, implemented, and improved over several semesters until it was ultimately abandoned due to its ineffectiveness and large size. The software was converted to Java to improve portability and reduce dependence on non-Java-based programs. Software to implement a speech output for the robot was also completed. Later, a new motion controller was purchased and the corresponding software was rewritten for it. This leads up to the current condition of the robot, which will be discussed in the next section.

1.1.4 Current AccomplishmentsAt the beginning of the semester, the robot clearly needed considerable work to get it into running condition. A bulky end effector, lack of power, slipping belt-drive, nonfunctional remote interface, and a poorly-documented sensor array hindered the desired functionality of the robot. For the end effector, a simpler design was needed that could be contained within the robot chassis. The new design has been developed and parts are being ordered to proceed with the

1

implementation. The drive train and power system were entirely revamped as well. The wheels received new bushings which stopped the belt slip problem. After a new battery was installed, the wiring was completely rerouted and new interface panels were installed to make them externally accessible. The existing software was significantly overhauled in order to support the new remote interface and to provide for better error handling. Further, a GUI has been developed that makes robot operation clear and simple. The sensor system was not in the condition perceived at the beginning of the semester – in fact, it was not operational at all. Due to poor sensor documentation, a lot of time was spent gathering descriptions of the sensory hardware so that it could be adequately tested. Faulty sensor wiring was also discovered and redone; however, that did not completely fix the problem. Except for these problems with the sensors, the project is progressing as planned.

1.1.5 Work To Be CompletedThere is a significant amount of work yet before the robot can be considered complete. Immediate work will involve fixing the sensor array. Once communication has been established between the sensory hardware and the computer, work on characterizing the sensors can continue. While the sensors are being fixed, a navigation algorithm needs to be designed so that it can be tested once they are operational. In order to get wheels to turn at the same rate while driving straight, the wheel tachometers need to be installed. To accomplish this, a circuit needs to be built to interface the tachometers with the motor controller. Now that the new end effector design is complete, it can be built as soon as all parts and motors arrive. Once assembled, a controller will be added so that will be able to interface with the computer. Since the basis for the GUI control software is complete, future work will focus on adding speech control as well as functionality from other aspects of the robot as they are completed. These aspects include: sensor feedback, wheel tachometer feedback, and end effector control. All topics summarized here will be discussed in more detail in future sections.

1.2 Problem StatementThe following problem statement covers all the major issues that need to be overcome in order to successfully arrive at the end product.

1.2.1 General Problem StatementThe overall task at hand is to develop a fully functional robot that the university can use for demonstrations to visitors. To be a success, the robot needs 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 must have an effective way to 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 final design should be able to fit inside one layer of the existing robot chassis. The onboard computer is responsible for controlling all components previously mentioned. An easy-to-use software package must be developed so that an average person could be capable of operating the robot. The software must communicate with the robot wirelessly so that no cables need be attached. Speech control also needs to be implemented as an alternate method for operating the robot. A logical approach to resolving these problems is discussed next.

2

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 an appropriate battery can be used. 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 more easily and 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. 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 shall 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 purchased.

1.3 Operating EnvironmentThe end product shall operate in the following, controlled environments:

A typical classroom setting or under ideal (sunny, warm) outdoor weather conditions. Acceptable temperatures may range between 14o and 33o Celsius and the humidity level

may vary between 0% and 90%. On a flat surface such as a smooth floor. There must not be any stairs or other drop-offs

in the area. If obstacles are present, they must be at least 2.5 feet high.

1.4 Intended Users and Intended UsesThis section documents the intended users and the intended uses of Project OSCAR.

1.4.1 Intended UsersOnce the GUI has been developed, most any person will be able to control the robot manually or through prewritten, automated scripts. That person must be familiar with what command each input box corresponds to, as well as the meaning of information written to the output screen on the control software. A team member must be present in order to supervise the respective user and to handle any problems that may arise.

1.4.2 Intended UsesThe robot will primarily be used for demonstrations to campus visitors. The intention of the demonstrations will be to show what types of projects engineers can be involved with and hopefully to generate interest in the engineering profession as well. The end product’s demonstrable capabilities will include:

The ability to manually control the robot via GUI software, The ability to map and navigate autonomously a corridor or room, The ability to pick up and place objects with the end effector, The ability to speak, and The ability to be controlled by spoken commands.

3

1.5 Assumptions and LimitationsThis section documents the assumptions and limitations under which the Project OSCAR team operates.

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

Any operator of the end product shall demonstrate proficiency with the English language. Any operator of the end product shall be familiar with the operation of the control

software. Trained team members shall be present when the robot is being operated. 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 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 to perform occasional presentations. To maintain a wireless connection, the robot can be no more than 328 feet away from the

computer controlling it (see Table 4.28 : D-Link DWL-122 Specifications). Under a full battery charge, the robot shall not remain in operation for more than one

hour. All systems must reside within in the robot’s chassis. The width of the chassis is fixed at 30 inches.

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. The following components are 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 Room/corridor navigationo End effector controlo 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

2 Project Accomplishments and Current StatusThe following section documents the accomplishments made working on the project to date and its current status.

2.1 Previous accomplishmentsThis section details the accomplishments from previous semesters. No claim is made as to their validity, as there is little to no documentation of previous work; in fact, many claims are inconsistent with the state of the project at the beginning of the semester.

Prior to Spring 2001:o Under Project CYBOT, the general project definition and research into sensor

types was performed. This information carried over to the current project. o A problem definition for the motion-control abilities was created.

Spring 2001:o Driver code for the motion-control hardware was developed and a rudimentary

GUI was developed for use with it. o The PCB design of the connection boards for the SONAR transducers, BasicX24,

and MUX was createdo Initial programming of the BasicX24 was performed.

Fall 2001:o Problems with original motion-control code were fixed.o Work was begun on a speech control subsystem. o The original sensor code was reworked and the final programming of the MUX

and BasicX24 was finalized. o Compass sensor research was performed. o An arm assembly and the base motor control scheme were researched and

designed. Spring 2002:

o An upgrade process was begun to cope with the demands placed upon the onboard computer by the speech recognition process.

o Software was created to properly interpret the data being received from the SONAR subsystem.

o Research into CCD cameras and frame-grabber hardware were performed. o A gripper arm was designed and assembled, which included a circuit board and

the requisite programming to control it. o The base motor control scheme was implemented and tested.

Fall 2002:o Incremental improvements to the robot’s code base were performed, including

refinements to the voice control and the motor control, prompted in part by the discovery of small errors.

o Another rudimentary GUI was integrated into the robot’s controls. o The gripper and its board were tested. o A DC/DC converter was designed.

Spring 2003:

5

o Functional motion-control hardware was unavailable, and therefore the majority of the software-related efforts were devoted to documentation and upgrades of coding tools.

o The components for the arm were machined, and its control board was created and tested.

o The DC/DC converter was fabricated.o Sensors were installed on the battery.

Fall 2003:o A development environment was created to store valuable documents.o The project’s code base was converted to Java to improve portability and reduce

dependence on non-Java-based programs. o Text-to-speech ability was implemented.o The sensor and motion-control interfaces were redesigned. o The hard drives were networkedo A faulty sensor microcontroller and several faulty transducers were replaced.o The sensor’s connection board was redesigned. o The fabrication and machining of the arm was continued. o The previously-designed base motor-control scheme was abandoned, and new

methods were researched.o The previous arm design was seriously reconsidered and new approaches were

developed. o Testing of the DC/DC converter was continued.o The power system was documented.

Spring 2004:o Speech recognition was researched and a solution was found.o A wireless card was acquired to remotely control the robot. o Code was written to interface with a brand new motion controller.o An upgrade to the processor was researched but not implemented due to financial

restrictions.o The project website was redesigned. Pictures were added.o Navigation methods were researched.o The implementation of mapping solutions was begun.o An object-avoidance self-navigation solution was begun.o A new motion-control solution was implemented.o New PCB’s for the arm-control circuit were designed but not fabricated.o The arm design was reworked to make it lighter.o Battery indicators were rewired and show remaining power percentage and

current amperage.o Peak power usage documentation was created.o Access to charging cables was improved.o Documentation of the battery indicator was created and a document was created

with instructions on charging and maintenance.

6

o Completed testing of DC/DC power supply: neither the combined nor separated boards maintained the proper voltage under load. New power supplies were researched.

2.2 Present accomplishments Create SONAR array reference material Completion: 100%

This has been the foremost task because of the sheer lack of documentation that has been cataloged and passed down from previous teams. Basically starting from scratch, specifications and schematics have been compiled for much of the major components. Continued work needs to be done on the remaining ICs on the sensor boards and creating accurate and usable schematics for the custom made circuit boards.

Document SONAR testing from Spring 2004 Completion: 100%After much frustration, the test inherited from last semester has been found completely unusable. Investigation reveals that there is no communication taking place between the compass and the software, and therefore no real data is being displayed. The code simply outputs one value hard-coded into the program. Documentation has been completed to the extent of the usability of the tests that currently exist.

Document existing software Completion: 100%The location of previously-existing software in the CVS Repository was determined, and it was reviewed to develop an understanding of its functionality. During this process, comments and other descriptors were added using the Javadoc, which allows a description of the classes and methods to be extracted from the code and placed into a document. The existing software was then tested for functionality. It was determined that the existing software was not robust enough for use in the project and would not support the implementation of the desired remote interface; however, the software was functional enough to serve as a base for future revisions.

Consider end effector control solutions Completion: 100%It was found that the purchase of a standalone control unit for the motors on the end effector unit would be too costly for the budget of this project. The design and implementation of custom solutions for each motor is easy and cheap enough for undergraduate students to undertake.

Complete SOP for testing SONAR Completion: 0%Because no high-level functioning tests are available, this task has begun to develop lower level component tests for each part. This process is behind schedule and will not be completed this term.

Consider DC/DC converter solutions and make purchase Completion: 100%Multiple power conversion products were considered. It was decided that:

o The cost of a DC ATX power supply is too large for the average semester budget. o DC/DC power conversion units cannot supply the power needed to run a modern

computer system.o A new DC/AC inversion unit with larger power handling capability will be the

best solution for project budget and implementation modularity.A DC/AC unit has not yet been purchased because of budget constraint. It will be purchased next semester.

7

Design new end effector Completion: 100%Alternative designs where created and analyzed to decide which ones best fit the current application. Once the overall design was chosen, the sizes, lengths and operations of the different applications on the end effector where selected. When the functions and components of the design where finalized, a three-dimensional model of each component was created, detailed and analyzed. This was done to determine the weight and strength of each part and of the entire assembly.

Develop navigation algorithm Completion: 5%Due to a lack of documentation from previous semesters, there were no references to use as a starting point; therefore, all research this semester started from scratch. Currently, research of navigation algorithms is in progress, and there are serious concerns as to the viability of completing this task this semester. Research has not progressed to the point of developing even a simple navigation algorithm.

Design controller for end effector motors Completion: 0%To avoid budget expenditure, a homemade board will be designed using classical and loop-shaping control theory techniques. Time permitting, a robustness analysis will also be applied to the design to ensure that multiple loads can be manipulated safely. The implementation of this board will not be completed this semester because of the time taken to order electrical components from manufacturers.

Design suspension system for drive train assembly Completion: 0%An effective suspension system will be investigated and designed for the chassis or wheel assembly. When completed, the suspension system will eliminate most of the unnecessary vibration and the danger of high-centering. This task will likely be eliminated because it is not significant to the desired end product.

Develop control infrastructure Completion: 100%The existing code was rewritten and updated to allow for a more logical interface and now allows commands to be issued via a command-line interface. The robot is now controlled via a series of simple commands, such as ‘forward’, ‘left’, ‘right’, or ‘backward’, and the length of time in milliseconds for the command to run. This implementation also allows a speech command to be issued by entering ‘say’ and the phrase the robot should speak. Because the sensors are not currently functional, sensor capability has not been tested in this implementation.

Develop remote interface Completion: 100%To support the wireless adapters used for communication between the robot and a remote computer, a new operating system was installed. The robot now runs a simple web server that accepts a connection from a client and allows the robot to be controlled remotely via a command-line interface. Further, a Java program has been written to accept a connection from the client-side GUI, start the command program, and interpret and issue remote commands to the command program. The client-side GUI is completed and can successfully connect to the server program.

Develop GUI for end-user interactivity Completion: 100%Because there is no reason for this portion of the program to be written in the same language as the rest of the program, C# was chosen for development because it preserves platform independence and because the Microsoft Visual Studios suite contains useful GUI creation tools. Screenshots were first developed to reflect the planned design and layout. The GUI was then developed to reflect all available functionality currently

8

available to the robot. Sensor output and scripting support will be added once the sensors are working. End effector control will be added once the control circuit is developed.

Fix current drive train subsystem Completion: 100%A manufactured polymer bushing was used to replace the bearing in each wheel. The wheels were pushed to one side of the axis which removed axial motion and play, and eliminated the belts rubbing on the wheels.

Implement new end effector Completion: 0%With end effector design only recently completed, attempts for construction have just begun. The design has been created to support motors already in our possession, but other components are still needed. To improve the quality of the final product, the implementation of the end effector will be delayed until next semester.

Install wheel tachometers Completion: 0%It was found that the “tachometers” acquired in Spring 2004 are actually optical encoder units. A circuit will have to be designed and implemented to convert the output of the encoders to a form useable by the RoboteQ motor controller. Solutions have been considered and a board design will be created next semester.

Reroute wiring and install interface panels Completion: 100%The wiring in the bottom module was completely removed and replaced. New wiring was implemented according to necessary current load and potential use cases.

o Wires were kept out of the way by running them along chassis bars and away from the moving parts in the module.

o All new wires were labeled in coordination with a schematic of the power delivery system.

o Fuses and recharging connections were made externally accessible.o Switches were added and labeled so that non-technical users could easily turn the

system on and off, and recharge the battery.o Since a second battery was not in use, the RoboteQ motor controller was mounted

on the free battery shelf to aid heat dissipation. Create external façade for end product Completion: 100%

A façade was created according to the specifications set forth in the Project Plan document.

o A hinged structure that can be opened at only one point was built to secure the internal components of the robot.

o A mechanical lock was added to prevent unauthorized access. Characterize SONAR array Completion: 0%

Because a functioning array with test software is needed to be able to analyze the data for algorithm development, no work has yet been done on this task Completion of this task is not expected this semester. Once test software has been written in the Spring 2005 semester, this task will be resumed.

Develop SONAR array test software Completion: 0%Because a method for communicating with the SONAR array currently does not exist, this test software cannot be developed.

Test new end effector Completion: 0%Testing of the end effector assembly has not yet begun because it will not be implemented this semester. Testing will be conducted in the future of the project, after it has been fully assembled.

9

Test newly-developed software Completion: 100%All of the newly-developed software has been tested and found to conform to the established requirements. This includes the GUI, command interpreter, network, motor control, speech, and serial port software. Although generic sensory software has been written, it cannot be tested until the sensory hardware is functional. When this functionality exists, further testing will take place at that time.

Create electromechanical system wiring documentation Completion: 100%An electrical schematic of the new wiring system was created. Wire labels on the schematic correctly match wire labels on the actual system.

Purchase new battery Completion: 100%The existing batteries had been destroyed by operation without fluid inside the cells. New battery solutions were considered, and a maintenance-free, sealed battery was purchased as a replacement.

Document newly developed software Completion: 100%Documentation of software has progressed as the software is developed. All software is currently located online and on the robot in a well-marked directory, and a database of classes and methods can be found online. Complete documentation of the software may also be found in section 4.6.7 on page 12 of the Appendix.

Develop scripts for end product demonstration Completion: 0%The GUI has been implemented and the creation of a script or macro for use in a demonstration would be trivial: the user simply chooses to record a macro and then guides the robot around a room. This task will not be completed because the sensor array is inoperable and running scripts would be dangerous if the robot cannot detect its surroundings.

Research image-processing options Completion: 0%Because this task was of little urgency, it has not progressed to a point where there is a concrete recommendation for what specific technology the project should adopt in the future. Technologies considered include National Instruments real-time system integration with image acquisition (IMAQ) with help from Kevin Crotty in the Image Acquisition group. Possible requirements include use of the Labview development suite and CCD digital imager.

2.3 Required future activities Implement tachometer unit circuit boards Spring 2005

In the event that the components necessary cannot be procured by the end of this semester, interface boards for the tachometer units will have to be built and installed this semester.

Select and purchase a new DC/AC inverter Spring 2005A unit that can handle the load of a modern computer will need to replace the current unit.

Implement end effector Spring 2005With the design completed in Fall 2004, the end effector is now ready to be assembled. Many of the motors from the original arm have been included in the new design. Any other materials that can be salvaged from the original arm will also be used. Other needed materials will be researched and purchased accordingly. Once built, the end effector will be installed on the upper layer of the robot.

10

Design end effector control circuits Spring 2005A control circuit needs to be designed to support the end effector once it is developed.

Develop speech control Spring 2005This task has been researched by past semesters, but has yet to be implemented. It will be much easier to speak commands to the robot instead of typing them every time. The first objective will be to choose some existing speech recognition software that has support for the robot’s operating system. Once this has been found and installed, the actual implementation should not be too difficult. A predefined list of spoken commands will be generated and assigned to a corresponding robot operation.

Fix sensor array Spring 2005A working SONAR array and compass are requisites before continuing any further. Verifying operation of transducers, SONAR ranging modules, and microcontrollers will need to be continued and standardized tests will have to be developed in the future, with test circuits and software ready to test anything right out of the box or right off the robot. Further understanding and documentation will have to take place to develop methodical testing procedures to guarantee the sensor systems are fully operational. This could take considerable effort to design and build test these new circuits and software, but worthwhile as OSCAR continues to age, facing obsolescence and breakdown problems.

Depending on the results of future testing, financial resources may be needed to replace some components of the array, as shown in Table 2.1.

Table 2.1 : SONAR array replacement component s

Component Make and model Estimated price

Microcontroller BasicX-24 $50.00SONAR transducer Senscomp 600 series $27.00Ranging module Senscomp 6500 SMT $36.00Compass sensor Dinsmore (part #1655) $37.00

Optimally, realizable tests will be ready early next semester and all of the hardware components will be fully functional by then. Should some of the components continue to fail, there is a potential that complete tests will not be completed by the end of next semester. Further, this eventuality would likely push other tasks behind schedule.

Characterize sensor array Spring 2005Obstacles will be placed around the robot in a manner that explores the range (both minimum and maximum), depth, and height of the area in which the robot can sense. Return data will then be observed and examined, with the intent of determining what the robot senses, what it does not sense, and how it interprets it. This cannot be completed until the sensor array is in working order.

Complete SOP for testing SONAR Spring 2005Though many of the lower-level testing procedures have been developed this semester, lack of a working SONAR array has restricted the ability to produce a high-level testing procedure for the array. This task will have to be renewed next semester and completed before the navigation algorithm is finalized.

Implement end effector control circuits Fall 2005

11

Circuit boards for end effector motor control must be built according to designs created during the previous semester and installed appropriately.

Develop end effector control software Fall 2005When the end effector has been assembled, complete with all of the control motors, software will need to be written to interact with the motor controller. This may take more than one semester because a motor controller does not yet exist. Once an interface between the software and end effector has been created, it can be easily extended to be a part of the GUI (currently in development). By being part of the GUI, any potential user should be able to manipulate the robot’s end effector.

Develop navigation algorithm Fall 2005A working sensory array is a prerequisite to this task. The condition of a successful algorithm will be starting the robot and allowing it move down a hall without running into anything. The robot will have to use input from all eight SONAR arrays to comprehend what short- and long-range obstacles are approaching and the most efficient way to maneuver around them. Testing and optimizing the algorithm will occupy most of the time for this task.

Design and implement active façade Fall 2005The top level of the façade must be designed to make way for the end effector during its operation and hide the end effector when retracted.

2.4 Current project and end product statusThe end product has been heavily modified and improved this semester.

2.4.1 Computer SystemExtensive work was put into the computer system this semester. This section details that portion of the end product.

2.4.1.1 HardwareSeveral changes have been made to the computer system hardware over the course of the semester; however, no changes have taken place in the overall design or appearance of the robot. These changes include:

The addition of a new hard drive, increasing the available hard disk space to 27 gigabytes, and allowing more storage for old code, new code, and any other programs which may be necessary for the completion of the project.

The addition of a wireless adapter, which now allows a laptop to interface with the robot. This has effectively eliminated the need to plug a keyboard or monitor into the robot for testing. This step was because the monitor and keyboard restricted the robot’s range of motion while being tested.

No further changes to the computer hardware are currently being considered; however, it is possible that the addition of voice recognition software to the project may require future upgrades in following semesters. It is also important to note that a method for interfacing with the end effector needs to be created, as the two serial ports are currently in use.

12

2.4.1.2 SoftwareDocumentation of all classes and methods can be found in Appendix 4.6.7.

2.4.1.2.1 Documentation of CodeThe code on the robot has been sorted, and all code currently in use has been documented and placed in a single directory on the robot. Also, this code is located online in a well-marked folder. This eliminates the situation which the software team found itself in at the beginning of the semester, where the location and function of all the previously-written code were unknown. Future teams will have immediate access to all developed code and a summary of its function.

2.4.1.2.2 Control InfrastructureUpon inspection of the previously-existing code, it was discovered that this code did not support the goal of creating a control infrastructure which would encompass the robot’s functionality into a single program; therefore, the software for the robot has been rewritten:

The existing code was updated to include more comprehensive error-checking, which improved the robustness of the programming in general and prevented or handled certain problems, such as invalid signals, which may have crashed the program.

An intermediate level of programming was created which abstracts the serial interface between the components and the software into a control class which translates the command parameters into a more human-readable interface.

At the top level, a monitor program has been created which starts the command process and controls the flow of commands to it. Should the command process terminate unexpectedly, the robot may not stop moving. This process makes sure that, in the case of unexpected termination, the robot is still under control.

These changes mean that the programming for the robot is more dynamic. Further, in contrast to the code as of the beginning of the semester, it will not require several weeks of study before additions or revisions can take place in following semesters: the only requirements will be the specification of an interface for any new functionality and the addition of that interface to the current control class. Figure 2.1, below, depicts how the software classes work together.

13

Figure 2.1 : Software interface diagram

2.4.1.2.3 Remote InterfaceIn addition to the control infrastructure, functionality which supports a remote interface has been added to the robot:

14

As mentioned previously, a wireless adapter was added to the robot to allow a remote connection to take place.

The operating system on the robot was upgraded to Mandrake v.10.1 because the existing operating system did not have driver support for the wireless adapter.

Another level of programming was added which will both accept the remote input and send it on to the control program. This allows the client-side interface to communicate with the robot via a prescribed interface: should something change in the implementation of the control class, it will not require a major revision of the client program.

A GUI has also been developed to allow a user to communicate with the robot without having to learn the syntax and structure of the command-line interface.

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

Figure 2.2 : Normal mode layout

2.4.1.2.4 Main WindowFigure 2.2 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

15

well as control movement speed and turn speed; the Speech section allows the user to enter a string of text and then command OSCAR 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.

Figure 2.3 : Advanced mode layout

Figure 2.3 is a screenshot that 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 OSCAR.

2.4.1.2.5 Drop-down menusThe following screenshots show the menu system. The File menu allows the user to perform basic commands such as establishing a connection with OSCAR, commanding OSCAR 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. Figures 2.4 through 2.6 show these functionalities.

16

Figure 2.4 : File menu

Figure 2.5 : Script menu

Figure 2.6 : View menu

2.4.2 Sensor SystemThe sensor system has been the source of many schedule delays this semester.

2.4.2.1 ResearchDocumentation of research conducted this semester can be found in §3.2.2.

2.4.2.2 Current StatusWork with the sensors has fallen behind this semester, largely due to a sudden and inexplicable loss of sensor functionality. This, by itself, would not have been a significant problem; however, no documentation of the previous semester’s efforts—or even a testing procedure that prior teams might have used—could be found. Though one of the tasks for this semester was to create

17

this documentation, component testing was not, and it was testing that took most of the time this semester. Much effort has been expended to identify the hardware that has been put on this robot, starting from step one. Documentation has been gathered for many of the hardware components, and is available in Appendix 4.6.6.

Because so much of the work for this semester centered on documenting the existing hardware and developing future navigation capabilities, many of the deliverables have not been met, such as a characterization of the array and a development of standard operating procedures for testing the array – at least not at the software level, as intended. Low-level testing, however, has taken place and is documented in §3.4.2.

2.4.3 Electromechanical SystemThe electromechanical system has seen drastic changes this semester. The power delivery system and end effector assemblies have been completely redesigned.

2.4.3.1 Power SystemThe wiring in the bottom module was completely removed and replaced. New wiring was implemented according to necessary current load and potential use cases.

Wires were kept out of the way by running them along chassis bars and away from the moving parts in the module.

All new wires were labeled in coordination with a schematic of the power delivery system.

Fuses and recharging connections were made externally accessible. Switches were added and labeled so that non-technical users could easily turn the system

on and off, and recharge the battery. Since a second battery was not in use, the RoboteQ motor controller was mounted on the

free battery shelf to aid heat dissipation.

18

Figure 2.7 : Photographs of power system implementation

A schematic of the wiring system follows. As stated above, all wire labels in the actual system correspond to line labels on the schematic.

19

Figure 2.8 : Power system schematic

The RoboteQ motor controller will operate with a supplied battery voltage of 10-15 volts.

A battery charger was modified with color-coordinated banana plug connectors to facilitate battery recharging (see Figure 2.9).

20

Figure 2.9 : Modified battery charger

A simple user’s manual was created to teach non-technical users (including software programmers) how to operate the power system’s controls and read the monitoring panel. The manual can be found in Appendix 4.6.1.

The robot draws current from a sealed battery. The features of the battery (Optima D34/78) are found below. It is a 6-cell, deep-cycle battery with a 12Vdc nominal output. In comparison to either of the old batteries, it:

Has smaller physical dimensions, so it will fit in the same spot on OSCAR, Can be cycled deeper, to allow longer operating capacity, Can be mounted in any orientation (even upside down), whereas the others could not, and Does not have to be refilled.

21

The battery’s cycle length is illustrated in Figure 2.10. This figure was provided without supporting data by the customer support staff at Optima.

The specification sheet provided by Optima can be found in Appendix 4.6.2.

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.10 : Cycle length of Optima D34/78 battery

2.4.3.2 End EffectorThe end effector has been completely redesigned to make it more applicable for the robot. The new design was tested for strength and weight to determine its limitations. The end effector will also be able to meet rotational specifications for each section given below. Detailed drawings of each component in the end effector assembly are shown in the figures below. The end effector design can be broken down into five component assemblies: the gripper, wrist, forearm, upper arm, and base.

22

Figure 2.11 : Gripper assembly Figure 2.12 : Wrist assembly

Figure 2.13 : Forearm assembly Figure 2.14 : Upper arm assembly

Figure 2.15 : Fully assembled arm Figure 2.16 : Base assembly

23

Figure 2.17 : Fully assembled end effector

The current design is composed of the following degrees of freedom: Pivoting Shoulder Joint

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

o Rotate from 0° to 180° in the X-Y plane in a 3-second time span. Retracting Shoulder Joint

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

Pivoting Elbow Jointo Has a pivoting range around the X-axis from -90° to 90°o Pivots from -90° to 90° in a 4-second time span.

Rotating Wrist Jointo Rotates 90° about the axis defined by the forearm, originating about the X-Z

planeo Rotates from 0° to 90° in a 3-second time span.

Opening/Closing Grippero Manipulates objects up to 3.5 inches in width and up to 5 pounds in weight.o 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.2 below.Table 2.2 : 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.

24

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 assembly are given in the table below.

Table 2.3 : Physical dimensions of the end effector

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

25

Table 2.4 : Weight of components in gripper

Component Unit weight 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.5 : Weight of components in forearm

Component Unit weight 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.6 : Weight of components in wrist

Component Unit weight 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.7 : Weight of components in upper arm

Component Unit weight 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.8 : Weight of components in base

Component Unit weight 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.9 : Total weight of assembled components

Assembled Component

Combinedweight 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

2.4.3.3 Drive SystemThe drive train consists of two wheels with separate motors. Each motor is connected to a pulley-belt system with a reduction of 25:279, as shown in Figure 2.18. The wheels are mounted on the

26

chassis with individual axles. Each wheel has a pressed fit bushing made of high density polyethylene to reduce friction and to eliminate wheel runout and belt rubbing.

Figure 2.18 : Drivetrain physical components

The drivetrain is powered by the RoboteQ model AX2500 motor control unit, shown in Figure2.19. A wiring diagram for the unit can be found in Appendix 4.6.3.

Figure 2.19 : Drivetrain motor controller

Tachometric feedback is provided by US Digital model S1-256-B optical encoders. These encoders cannot directly output information to the RoboteQ motor controller, since they output a binary pulse train, and the controller requires an analog voltage input. A data conversion circuit must be designed and implemented to convert the output of the encoders to this form.

2.5 Recommendation for continued effortAt this point, we recommend continuing the project in the direction of our current vision. OSCAR continues to be a multi-disciplinary challenge that provides a valuable learning experience for all involved. In this plan, we have outlined many successes and many areas for improvement with a clear idea of what can be done to progress into more advanced fields of robotics.

27

By its 8th semester, the robot has seen hardware and software upgrades that have brought it new technological advancements, but there are always new things to add and old things to fix or be maintained.

One foreseeable problem, and one we began to encounter this semester, is the steep learning curve of implementation of modern methods of robotics that require a lot of research and a high level of understanding – sometimes greater than that which team members have been introduced to in their undergraduate curriculum. This is not to say that progress cannot be made or understanding cannot be obtained or mastered: rather, that in a three-credit course it can be hard for one or a few people to build the knowledge to make substantial contributions to the project. This is the greatest challenge faced by OSCAR.

A major frustration this semester was the lack of organization and vision from previous semesters, which seems to be a major problem with ongoing projects; however, with proper documentation, leadership, and foresight, this project can provide valuable senior design experience for semesters to come.

28

3 Documentation of current efforts and resultsThe lack of proper documentation has been recognized as a constant source of difficulty in continuing the work of this project. A strong focus has been placed on creating high quality documentation that can be used as a reference by future teams.

3.1 Project definition activitiesThe project milestones as proposed in §2.11.1 of the Fall 2004 Project Plan document were found to be unsatisfactory. They insufficiently captured the expected result of this semester’s work. A new list of milestones was used to reorganize the same set of tasks set forth for the semester. The old milestones are contrasted with the new ones in Table 3.10and Table 3.11. The task assignment to the new milestones is shown in Table 3.12 was assigned according to the same rules followed for the old milestones (see Fall 2004 Project Plan, Appendix B).

Table 3.10 : Old Milestones from Fall 2004 Project Plan

# Milestone Priority (%)1 Current product documentation 122 Technology selection 53 End product design 284 End product implementation 135 End product testing 176 End product documentation 57 Project reporting 128 End product demonstration 69 Research 2

Table 3.11 : New Milestones

# Milestone Priority (%)1 Drive motion 292 Speech Output 23 External Façade 14 End Effector 165 Navigation 386 Suspension 17 Research 18 Demonstration / Presentation 39 Project Reporting 9

29

Table 3.12 : New Milestone task assignments

Milestone Project priorityDrive Motion 29%Develop motion control software infrastructure 4%Develop remote interface 4%Rewire power system 3%Document existing software 3%Fix inverter and battery troubles 3%Create wiring documentation 3%Develop data link 4%Develop scripts and macros for demonstrations 2%Fix drive train 2%Install wheel tachometers 1%Speech Output 2%Develop speech output 2%External Façade 1%Create external façade 1%End Effector 16%Consider arm control solutions 3%Design controller for arm 3%Design new end effector 4%Implement new end effector 3%Test new end effector 3%Navigation 38%Create SOP for SONAR testing 4%Create SONAR array reference materials 4%Characterize SONAR array 6%Develop navigation algorithm 6%Develop SONAR array test software 6%Develop GUI 4%Document new software 2%Test new software 4%Develop scripts and macros for IRP 1%Report of SONAR testing from S04 1%Suspension 1%Design new suspension 1%Research 1%Research image processing 1%Demonstration / Presentation 3%Demonstrations to campus visitors 0%Industrial review presentation 3%Class presentation 0%Project Reporting 9%Project Plan document 3%Bound Project Plan document 1%Poster 1%Status Report document 3%Bound Status Report document 1%

30

This new milestone definition allowed progress to be tracked alongside tangible accomplishments. It provided a more intuitive sense of the project’s development, and facilitated management more effectively. In addition, by reusing the same tasks set forth at the beginning of the semester, actual effort prioritization was not changed. Thus, all recorded efforts in the new milestone scheme could be directly translated to accomplishments in the old scheme.

3.2 Research activitiesThere were several tasks this semester that required some research to be done prior to implementation.

3.2.1 Optical encoder interfaceIt was discovered half way into the semester that the optical encoders chosen for use in OSCAR to provide motor speed control are not directly compatible with the motor controller. Having discovered this problem we have come up with several solutions: Purchase add-on board RoboteQ makes for optical encoder interfacing to their motor

controller. Tachometers Frequency to Analog converters Microprocessor

3.2.2 Navigation algorithmResearch has been performed to determine how to navigate OSCAR down a hall. Through the research, it was determined that a fuzzy logic algorithm would be necessary to take the input from the sensors and generate the output to control OSCAR.

3.2.2.1 SONARIn Figure 3.20, the octagonal shape represents OSCAR, the 8 small circles represent the transducers, the arrows representing the signals, and the two dark lines represent walls. As OSCAR moves toward the direction shown, each of the 8 transducers sends out a signal, which hits the objects, and reflects back. Each of the transducers then receives this reflection and the array determines the distance to the object based on the strength of the signal.

31

Figure 3.20 : OSCAR in a hallway

If the sensors report that OSCAR is closer to an obstacle than the minimum distance allows, the navigation algorithm will calculate a deviation from the current trajectory to keep OSCAR at a minimum distance.

Direction of movement

signal

OSCAR

SONAR

WallWall

32

3.2.2.2 Limitation of SpaceIf the space available is smaller than the body of the robot, the robot will need to stop and find a larger space and move toward that path. All movement and detection will use SONAR as described above.

Availability of space

Availability of space

Figure 3.21 : OSCAR in limited space

3.3 Design activitiesDuring the course of the semester, several components were designed for implementation.

3.3.1 End effector designThe conception and design of a new effector were achieved using the following methodology:

For every degree of freedom in the effector, the means by which motion would be achieved had to be decided on. Specifically, designers specified the type of gear drive and geometry (such as worm, rack, or spur gear systems) that would be used in every degree of freedom. Worm gears were widely selected (primarily due to their ability to rule out unwanted motion), and a rack gear was used for its ability to create large translational motion.

Upon deciding on gear systems, gear ratios and motor sizing were accomplished by specifying range and duration of motion for the different joints taking into account specified and estimated loads and arm masses. Motors were selected based on their speed and power output. The following tables contain specifications of all electric motors found on the end product.

OSCAR

SignalsWalls

33

Table 3.13 : Drivetrain motor specifications

Specification ValueBrand DaytonModel 4Z143Nominal input voltage 12 Volts (DC)Service Factor 1Nominal ambient temperature 40 deg CBearings BallInsulation Class BRotation Clockwise and counter-clockwiseHorsepower 1/7Rev. per minute (maximum) 1750Full-load current 14 A

The following specifications (Table 3.14, Table 3.15, and Table 3.16) have been calculated for the end effector motors. They will be used as requirements during component selection.

Table 3.14 : Calculations for claw motor specification

Description Value UnitsAssumed coefficient of friction of rubber 0.55 x

Load weight 10 lbGripper length 4.5 inGear ratio 10.00 xGear torque 81.82 in-lbMin motor torque 8.18 in-lb

Motion range 60 degreesDesired lock-lock time 3 secGear speed 3.33 rev/minMotor speed 33.33 rev/min

Table 3.15 : Calculations for wrist motor specification

Description Value UnitsTorque desired 40 in-lbGear ratio 30 xGear torque 40 in-lbMin motor torque 1.33 in-lb

Motion range 90 degreesDesired lock-lock time 3 secGear speed 5 rev/minMotor speed 150 rev/min

34

Table 3.16 : Calculations for elbow motor specification

Description Value UnitsDensity of aluminum 0.0975 lb/in³Arm volume 17.93 in³Est. arm mass 1.748 lbSafe assumed arm mass 5 lbLoad mass 10 lbCG arm from elbow 7 inGear ratio 30 xGear torque 105 in-lbMin motor torque 3.5 in-lb

Motion range 180 degreesDesired lock-lock time 5 secGear speed 6 rev/minMotor speed 180 rev/min

Using specified gears and manufacturer data, arm geometries were created to accommodate the necessary gear mountings. Arm designs were created using Solidworks.

Arm lengths were modified to accommodate the specified motion criteria, allowing the arm to reach the desired envelope during operation and to fully retract when not in operation.

Portions of the arm which were deemed critical (or potentially too weak for operation) were analyzed using COSMOSWorks. Components which were found to be too weak were redesigned and reanalyzed. As an example, Figure 3.22 shows analysis of the forearm section under a 20 lb load. The strength of this section under load was deemed critical, and it was found to be sufficiently strong (factor of safety of 1.5).

Figure 3.22 : COSMOSWork Analysis of forearm under loading

35

3.3.2 Implementation activitiesThe project definition called for the implementation of end effector this semester:

The end effector will be constructed using in-house machined components as well as specified purchased items. Certain components have yet to be ordered or otherwise obtained, such as gears, rot material, and hardware. To minimize costs as many materials and components from the old end effector that can be utilized will be used.

Certain components will be fabricated from custom designs. To complete this task, group members will use 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.). Upon completion of assembly, the system will be mounted in a module on the robot and tested.

3.4 Testing and modification activitiesMany components this semester required testing to ensure functionality or troubleshoot errors.

3.4.1 End effector testingUpon completion of the end effector, the system will be fully tested to confirm adequate functionality and assess system capabilities. These tests will analyze the end effector’s ability to move through the required range of motions as described in §2.4.3.2. The tests will begin with the shoulder and progress through each section of the end effector testing each motor to make sure they all work properly. The speed of each section will also be tested to determine if the gear sizing was correct and that there is the proper amount of torque output by each motor to move the required amount of weight in the specified time. The lifting capacity of the end effector will also be tested by picking up progressively heavier weights until the target weight of 5 pounds is reached. If any of the predetermined requirements for the end effector are not met, the problematic section will be remade or fixed so it fits the requirements.

3.4.2 SONAR TestingThe sensor test software currently on OSCAR is not functioning properly and no successful software-level tests have taken place this semester. This meant that lower level hardware testing was necessary to find out what had gone wrong with the microcontroller, the SONAR ranging components, or the transducers themselves.

Before testing began, the frayed and tattered wiring had to be repaired on multiple areas on the sensor deck. The transducers were falling out of the supporting metal sockets in the frame and had to be glued back into place. The SONAR ranging module posts were loose and had to be grounded properly to the case.

36

Figure 3.23 : Circuit used for testing ranging modules

Testing began by verifying the operation of the model 6500 SONAR modules connected to one 600-series transducer triggered by an oscilloscope pulse, as shown in Figure 3.23. The test measured for the time required for the ECHO signal to go high after the INIT pulse was sent, as shown in Figure 3.24. Currently all the transducers are being tested to verify they are working properly. We have eight transducers currently on OSCAR and four spare units available from CYBOT.

Figure 3.24 : Signals used in testing sensor array

37

It is likely that the microcontroller is in need of reprogramming, as its reset pin may have been signaled. Once the microcontroller has been reprogrammed, there is a good chance that the sensor array will work.

3.5 Resources and SchedulesThe following section documents the resources used during the course of this project, and includes both estimates and the actual values to date.

3.5.1 Resource requirementsThis section documents the resources used working on this project. It includes both estimates and actual values for the time and financial requirements.

3.5.1.1 Personnel effort requirementsThis section documents the estimated and to-date time requirements for this project. A reference chart for task identification is given as Table 3.17.

38

Table 3.17 : Task description reference chart

Task Number Task Name

2.13.1.1 Create SONAR array reference material2.13.1.2 Document SONAR testing from Spring 20042.13.1.3 Document existing software2.13.2.1 Consider end effector control solutions2.13.2.2 Complete a standard operating procedure for SONAR testing2.13.2.3 Consider DC/DC converter solutions and make purchase2.13.3.1 Design new end effector2.13.3.2 Develop navigation algorithm2.13.3.3 Design controller for end effector motors2.13.3.4 Design suspension system for drive train assembly2.13.3.5 Develop control infrastructure2.13.3.6 Develop remote interface2.13.3.7 Develop GUI for end user interactivity2.13.4.1 Fix current drive train subsystem2.13.4.2 Implement new end effector2.13.4.3 Install wheel tachometers2.13.4.4 Reroute wiring and install interface panels2.13.4.5 Create external façade for end product2.13.5.1 Characterize SONAR array2.13.5.2 Develop SONAR array test software2.13.5.3 Test new end effector2.13.5.4 Test newly developed software2.13.6.1 Create electromechanical system wiring documentation2.13.6.2 Document newly developed software2.13.7.1 Develop scripts and macros for end product demonstration2.13.8.1 Research image processing options2.13.9.1 Project Plan document2.13.9.2 Bound Project Plan2.13.9.3 Project poster2.13.9.4 Industrial Review Panel presentation2.13.9.5 Status Report document2.13.9.6 Bound Status Report

3.5.1.1.1 Estimated RequirementsEstimated required personnel effort is tabulated below. The listings are broken into two tables to ease display and readability; sums shown at the end of each table are for all tasks.

39

Table 3.18 : Estimated personnel requirement 1

Personnel name

2.13.1.1

2.13.1.2

2.13.1.3

2.13.2.1

2.13.2.2

2.13.2.3

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

2.13.4.1

2.13.4.2

2.13.4.3

2.13.4.4

Sub-total

Gus Aramayo             38     6       3 41     88David Hawley     10               10   23         43William Hoang     7               7 6 15         35Zachary Kotlarek     8               6 14 14         42Michael Larson 4 6     16     14                   40Dung Nguyen 12 11     3     23                   49Huy Nguyen 11 12     7     22                   52Justin Ramussen     6               4 7 19         36Gavin Ripley     9               9   13         31David Staab       4   2     31             12 9 58Jason Sytsma       2   3     16             13 15 49John Walvatne             42     5       3 40     90

Total 27 29 40 6 26 5 80 59 47 11 36 27 84 6 81 25 24 613

Table 3.19 : Estimated personnel requirement 2

Personnel name

2.13.4.5

2.13.5.1

2.13.5.2

2.13.5.3

2.13.5.4

2.13.6.1

2.13.6.2

2.13.7.1

2.13.8.1

2.13.9.1

2.13.9.2

2.13.9.3

2.13.9.4

2.13.9.5

2.13.9.6

Total

Gus Aramayo       5           8 1 1   9 3 115David Hawley         11   3 8   9 3 1   11 2 91William Hoang     10   8   11 5   14 2   20 8 3 116Zachary Kotlarek         9   3 6   11 3 2   7 1 84Michael Larson   20             6 13 1 1   10 2 93Dung Nguyen   11             9 16 3   20 8 1 117Huy Nguyen   13             10 15 2   20 9 1 122Justin Ramussen     9   8   3 3   10 3 2   12 3 89Gavin Ripley         13   10 4   8 1 1   11 2 81David Staab 6         8       20 2   20 8 1 123Jason Sytsma 5         15       12 1 1   10 3 96John Walvatne       5           11 3 1   11 2 123

Total 11 44 19 10 49 23 30 26 25 147 25 10 80 114 24 1250

40

3.5.1.1.2 Actual Requirements (to date)Actual required personnel effort is tabulated below. The listings were broken into two tables to ease display and readability; the sums shown at the end of the tables are for all tasks.

Table 3.20 : Actual personnel requirement 1

Personnel name

2.13.1.1

2.13.1.2

2.13.1.3

2.13.2.1

2.13.2.2

2.13.2.3

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

2.13.4.1

2.13.4.2

2.13.4.3

2.13.4.4

Sub-total

Gus Aramayo 29 3 32David Hawley 7 25 10 42William Hoang 7 2 2 2 13Zachary Kotlarek 5 1 12 9 27Michael Larson 11 3 2 2 18Dung Nguyen 7 3 5 0 15Huy Nguyen 11 3 5 23 42Justin Ramussen 6 8 8 7 29Gavin Ripley 7.3 7.3David Staab 2 11 13Jason Sytsma 2 4 16 14 14 50John Walvatne 27 3 30

Total 29 15 34 2 12 7 56 25 16 0 47 28 2 6 0 14 25 318

Table 3.21 : Actual personnel requirement 2

Personnel name

2.13.4.5

2.13.5.1

2.13.5.2

2.13.5.3

2.13.5.4

2.13.6.1

2.13.6.2

2.13.7.1

2.13.8.1

2.13.9.1

2.13.9.2

2.13.9.3

2.13.9.4

2.13.9.5

2.13.9.6

Total

Gus Aramayo 8 2 5 49.5David Hawley 4 2 51William Hoang 5 5 8 12 45Zachary Kotlarek 1 1 2 1 1 10 1 3 1 53Michael Larson 0 0 16 9 6 67Dung Nguyen 0 0 13 5 52Huy Nguyen 0 4 5 6 69Justin Ramussen 9 18 1 8 25 94.5Gavin Ripley 2 4 21 19 69David Staab 12 2 41 1 1 18 91Jason Sytsma 8 11 3 10 84John Walvatne 9 3 14 60

Total 24 0 6 0 6 10 6 1 4 164 3 50 0 102 0 785

41

Table 3.22 : Additional personnel requirements

Personnel name

Presentations:

Troubleshooting

SON

AR

:

Project planning and tracking

Total:

Gus Aramayo 3     3David Hawley 3     3William Hoang 2     2Zachary Kotlarek 5     5Michael Larson 3 15   18Dung Nguyen 4 15   19Huy Nguyen 2 10   12Justin Ramussen 5     5Gavin Ripley 17     17David Staab 3   13 16Jason Sytsma 2     2John Walvatne 4     4Total 53 40 13 106

There are quite a few differences between the expected hours and the actual hours to date. Some of the differences, of course, exist because the semester has not yet come to completion.

The most significant differences are related to the sensors. As previously mentioned, the sensor array was non-functional at the beginning of the semester and significant time has been spent trying to troubleshoot the array and determine the problem instead of working on the defined task. Many of the tasks rely on a functional sensor array and cannot be accomplished until this is done. As noted in Table 3.22, a total of 40 hours were spent troubleshooting the SONAR array, an unexpected and otherwise undocumented task.

Though the control infrastructure seems to have developed according to estimates, in truth many of those resources were spent trying to get the control infrastructure to work with the sensor array – had the sensor array been operable, that task would have been completed far ahead of schedule. Further, because of the minor research associated with certain tasks, such as the development of the end effector, time spent varied considerably with the ease of locating the requisite information.

3.5.1.2 Financial requirementsThis section documents the estimated and to-date financial requirements for this project.

42

3.5.1.2.1 Estimated RequirementsEstimated required financial resources are shown below. Sums are given with consideration for estimated labor costs and without, since the team members are not actually paid for their labor.

Table 3.23 : Estimated financial requirements

Parts and Materials   W/O labor With Labor Wire tie bases $10.00 qty 25 $10.00 qty 25 Wire ties Free Free Wire labels Free Free 18 ga. wire Free Free 12 ga. wire Free Free 10 ga. wire Free Free 8 ga. wire Free Free Wireless ethernet card Free Free 27-gigabyte hard drive Free Free DC/DC converter $ 500.00 $ 500.00 Project poster(including printing)   $ 70.00 $ 70.00   Subtotal $ 580.00 $ 580.00 Labor @ $10.50 per hour      Gus Aramayo $ 1,207.50 David Hawley $ 955.50 William Hoang $ 1,218.00 Zachary Kotlarek $ 882.00 Michael Larson $ 976.50 Dung Nguyen $ 1,228.50 Huy Nguyen $ 1,281.00 Justin Ramussen $ 934.50 Gavin Ripley $ 850.50 David Staab $ 1,291.50 Jason Sytsma $ 1,008.00 John Walvatne $ 1,291.50

  Subtotal   $ 13,125.00   Total $ 580.00 $ 13,705.00

43

3.5.1.2.2 Actual Requirements (to date)Actual required financial resources are shown below. Sums are given with consideration for estimated labor costs and without, since the team members are not actually paid for their labor.

Table 3.24 : Actual financial requirements

Parts and Materials   W/O labor With Labor Wire tie bases $10.00 qty 25 $10.00 qty 25 Wire ties $ - $ - Wire labels $ - $ - 18 ga. wire $ - $ - 12 ga. wire $ - $ - 10 ga. wire $ - $ - 8 ga. wire $ - $ - Wireless ethernet card $ - $ - New battery $ 135.96 $ 135.95 27-gigabyte hard drive $ - $ - Façade components $ 17.56 $ 17.56 Bound Project Plan $ 20.96 $ 20.96 DC/DC converter $ - $ - Project poster (including printing)   $ 18.00 $ 18.00   Subtotal $ 202.48 $ 202.47 Labor @ $10.50 per hour      Gus Aramayo $ 519.75 David Hawley $ 535.50 William Hoang $ 472.50 Zachary Kotlarek $ 556.50 Michael Larson $ 703.50 Dung Nguyen $ 546.00 Huy Nguyen $ 724.50 Justin Ramussen $ 992.25 Gavin Ripley $ 724.50 David Staab $ 955.50 Jason Sytsma $ 882.00 John Walvatne $ 630.00

  Subtotal $ 202.48 $ 8,242.50   Total   $ 8,544.98

The actual values spent are somewhat different than the projected values because there were several components which had to be purchased which were not known at the time of the Project Plan document, such as the façade components and binding for the Project Plan document. Also unknown at the time of the writing was that the previous battery had been ruined by being run without fluid in the cells. A new battery was purchased in order to demonstrate the end product.. Upon investigation of DC/DC converter solutions, the decision was made not to purchase one and simply run the robot in its current configuration. The use of the mechanical engineering department’s scan and print services saved a considerable amount of money on the project poster.

44

The reader should note that the hours spent are only to the current date, whereas the original estimates were for the entire semester.

3.5.2 SchedulesThis section provides a view of this semester’s schedule and compares the estimates with their actual values.

3.5.2.1 Project scheduleThe following figures document the schedule for the completion of tasks this semester. The light blue represents the estimated schedule, while the black inside it represents the actual timeline for completion this semester. Portions of the task list were completed on-time, such as the motion control infrastructure and the documentation of existing software (tasks 3 and 5, respectively, in the table), and portions of the task list are not completed, but on schedule, such as the creation of SONAR array reference materials (task 36). Some tasks, however, are so far behind schedule that they have been delayed until next year, such as the development of the SONAR array test software. A large number of tasks have been delayed which relied on sensor functionality for their completion, such as the characterization of the SONAR array and the development of a standard operating procedure for its testing (tasks 30 and 34).

Deliverables are represented on this schedule by a star. All deliverables have been completed or are on schedule for completion, regardless of the status of the other tasks.

45

Figure 3.25 : Actual project schedule 1

46

Figure 3.26 : Actual project schedule 2

47

3.5.2.2 Deliverable scheduleThe following figure describes some of the deliverables for this semester and the expected functionality by that point. Though some of the functionality expected at certain deliverables is currently not completed (such as the sensor array), the nature of the deliverables is such that the schedule cannot change.

Figure 3.27 : Deliverable schedule

48

4 Closure MaterialsThis section provides relevant closure materials and appendices.

4.1 Lessons LearnedThis section breaks down and summarizes some of the lessons learned by the Project OSCAR team this semester.

4.1.1 What went well Acquiring materials: electrical wire and wiring material was needed at the beginning of

the semester to accomplish the tasks set forth. Since the budget was limited, acquiring all the material was potentially a challenge. However, it was found that local electrical companies were very generous in their support of university projects and made the acquisition relatively easy. The budget was then able to be used for purchasing a much-needed battery.

Rerouting wiring and installing interface panels: tremendous time and effort was spent in completing this task properly. The result was a clearly-organized wiring scheme that has externally-accessible fuses and recharging connections.

Wireless improvement: previous semesters had attempted to implement a wireless interface; however, the robot’s operating system failed to provide good support these systems. To overcome this, an operating system that provided better support was considered and installed. Furthermore, two new wireless adapters were donated and are currently used by the robot and the client computer.

Design of the end effector: the work in making a precise design for the end effector went very well. Once it is built, it will likely contain all the desired functionalities.

OSCAR demonstrations: during October, the robot was demonstrated several times to grade-school students. The demonstrations focused on the technical and non-technical aspects of engineering that are used to work on a project like this. The robot was driven around the room and later was taken apart so that students could see all of the components that made up the robot. Positive comments were received from all the visiting schools.

Project poster: the new poster design proved to be a success. A new color scheme, title bar, and diagram were created for it. All of these contributed to earning first place in the ongoing project category.

4.1.2 What did not go well Sensor array: the sensor array is the only component of the robot that can gather a

description of its surroundings. Not being able to have this feature has been a huge setback as to what functions the robot could perform.

Wheel tachometers: the robot needs the wheel tachometers so that the software can correct itself if it isn’t driving straight and make precise turns at different speeds. Not having this component has also significantly reduced the functionality of the robot.

49

4.1.3 What technical knowledge was gainedThe required tasks this semester required, in some cases, a considerable amount of technical knowledge. The following is a list of the important points:

Discovering a solution to an interface between an optical encoder with a digital output and a motor controller that required an analog voltage input proved to be educational. During the requisite research into this subject, technical knowledge of the operation of frequency-to-analog converters, digital-to-analog converters and micro-controllers was gained.

Writing and rewriting sections of the code base for use in the control interface required knowledge of some of the lower-level classes and interfaces. This information was researched and successfully implemented. Further, there was functionality that wasn’t completely obvious, such as the implementation of a child process in Java, which required a little research before the intended functionality could be added.

This project required the use of many productivity tools to complete: for instance, the Gantt charts were done in Microsoft Project, the main documents such as the Project Plan and Status Report required a large amount of knowledge of Microsoft Word; while tables and charts made during the project, including the task tracking document, used Microsoft Excel. Also, the project poster required use of Microsoft PowerPoint and, for some of the backgrounds and figures, Adobe Photoshop.

4.1.4 What non-technical knowledge was gained Documentation: when working on a project of this scope, it was soon realized that

documentation is key to reaching the end product in a timely manner. This semester, a lot of unnecessary work was repeated because there was no documentation to indicate that it had already been done. It is clear that documentation should always be a large part of planning and implementing any project. Every length will be taken to ensure that all documentation written this semester will be made available to future teams.

Effort coordination: it is a challenging task for twelve people to work towards a common goal on a relatively small robot. By following a well-defined schedule that assigns tasks to individuals as well as teams, efforts have been successfully coordinated all semester.

4.1.5 What would be done differently if you could do it over again Sensor troubleshooting: had the current trouble with the inoperability of the sensors been

known from the beginning, troubleshooting could have started much sooner, and may have been completed in time to implement a navigation algorithm. The capabilities of the robot can not be greatly enhanced until this system is working again.

Locating old documentation: It was recently discovered that a lot of valuable documentation was stored in the CVS repository. However, the team members were unaware of this. Having knowledge of this documentation from the beginning of the semester would have saved many wasted research hours.

4.2 Risk and Risk ManagementSome of the most important considerations during the course of any project are its risks. This section details the risks inherent in this project and the expected methods of handling them. It also mentions some of the risks this project actually encountered.

50

4.2.1 Anticipated potential risks and their managementRisks were identified and categorized according to their expected impact on the project.

4.2.1.1 High-Level RisksThese risks were deemed to have the largest impact on the project.

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

4.2.1.1.2 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.)

4.2.1.2 Medium-Level RisksThese risks were deemed to have a medium-level impact on the project.

4.2.1.2.1 Failure to complete assigned tasksBecause many tasks are dependent upon the completion of others, the failure of a team member to complete their task under budget and prior to the deadline could threaten the entire project. This situation shall be avoided through proper tracking of task progress. In the event that a task misses its deadline, the team members assigned to it shall double the time spent on the task until it is complete. If deemed necessary by the project advisor, the team leader or another team member shall assist in completing the task.

4.2.1.2.2 Cost of development exceeds expectationsFabrication and assembly of the end effector is 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. Any components deemed too complex to fabricate will either be reused from existing assemblies or acquired from companies through sponsorships or in kind donations.

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

51

4.2.1.3 Low-Level RisksThese risks were deemed to have the smallest impact on the project.

4.2.1.3.1 Failure to attend a meetingFailure of a member of the team to attend any meeting could result in a communication gap: this 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 that conducts the meeting.

4.2.1.3.2 Software testing shows bugs in codeDuring testing, bugs in the software will invariably appear and require additional time to fix them. If sufficient time is not given to the debugging process, either unallocated time will be spent debugging software (which deviates from budget and resource constraints), or the bugs will be left in the software and 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 (a function of importance of the portion of the program and likelihood of the risk) and repaired in order of decreasing risk.

4.2.2 Anticipated risks encountered and success in their managementSeveral of the anticipated risks were encountered during the course of the semester. This section explains what happened and how it was handled.

4.2.2.1 Equipment failureWhile preparing for a presentation, the team could not get the robot to run. The presenters determined that the problem was a lack of battery charge, which could not be easily fixed in the few minutes before the presentation. Quick thinking by the presenters resulted in a more detailed presentation. The robot was disassembled so students could see and ask questions about each component of the robot. The students still experienced a fun, interactive presentation, and thus the risk was successfully managed.

4.2.2.2 Software testing shows bugs in codeAfter the existing software was documented and reviewed, problems arose when testing began. The code to interface with the motion control serial port could not locate the port and therefore could not send any commands to move the robot. The code also was not written to check for errors and overall did not follow many of the object-oriented programming conventions. It was decided to abandon the old software and write new classes that implemented a more logical structure and appropriately handled errors. The existing software was used as a guideline during development. Since the schedule allowed for the reviewing and testing of existing software, developing new software did not put the team behind schedule.

4.2.2.3 Failure to attend a meetingIt is difficult to coordinate the schedules of twelve fulltime college seniors. This risk was encountered throughout the semester, which was expected. We managed this risk through the use

52

of email and phone calls to keep group members informed on the subject of missed meetings. No members were excused from work as a result of failed attendance.

4.2.3 Unanticipated risks encountered and attempts to manage themDuring the course of the semester, several unexpected risks were encountered. This section details the risks encountered and how they were managed.

4.2.3.1 Failure of the sensor systemThe sensors were supposedly in full working order at the end of last semester, so this risk was never considered. Last semester, successful tests were run on the sensor array. The tests resulted in a list of numerical data, which was never interpreted. During this semester, an attempt was made to run the same sensor test program. The test locked up and no usable data was attained. After rewriting all of the software, a simple test to interact with the sensor microcontroller was done with similar results. At this point, it was determined that the problem was likely the sensor microcontroller. Currently, the most likely outcome will be that the microcontroller needs to be reprogrammed. Meanwhile, all hardware elements of the sensors are being tested to confirm they are functioning. Even though attempts to manage this risk can be considered successful, the extra work has set back the completion of tasks associated with the sensors.

4.2.3.2 Wheel tachometers do not use expected interfaceTo get both wheel motors to work at the same rate, wheel tachometers needed to be installed. It was assumed that the tachometers could be directly wired into the motor controller. When it came time to install the tachometers, it was discovered that they were not compatible with the motor controller. The only course of action available will be to design a circuit to interface the tachometers with the motor controller. Because of this unforeseen risk, there is a chance that the wheel tachometers will not be installed this semester. It will depend on how promptly the parts currently on order arrive.

4.2.4 Resultant changes in risk management because of unanticipated risksThe leading cause of these unanticipated risks was making false assumptions. Risks are inadvertently created by assuming something to be true before confirming that assumption. The false assumptions we made were not included on the list of assumptions from the project plan either. To reduce the chance of encountering similar problems again, no assumption will be considered reliable unless it already exists on the assumptions list.

4.3 Project Team InformationThe following section lists pertinent information regarding the client, faculty advisor, and student members of Project OSCAR.

53

4.3.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.3.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.3.3 Student team information

---------------------------------------- Name: ARAMAYO GUSTAVO AUGUSTO Phone: 612-618-1789 Email: gus2@iastate.edu Department: MECHANICAL ENGINEERING Univ Address: 518 HAYWARD AVE City/State: AMES IA 50014 Home City/State: OAK RIDGE TN Classification: SENIOR ----------------------------------------

54

---------------------------------------- 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: HOANG WILLIAM Phone: 515-451-1212 Email: hung@iastate.edu Department: COMPUTER SCIENCE Univ Address: 4605 ONTARIO #3 City/State: AMES IA 50014 Home City/State: SIOUX CITY IA Classification: SENIOR ----------------------------------------

---------------------------------------- Name: KOTLAREK ZACHARY PETER Phone: 866-863-8801 Email: profplum@iastate.edu Department: COMPUTER ENGINEERING Univ Address: PO BOX 9062 City/State: AMES IA 50014 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: NGUYEN DUNG TRI Phone: 515-778-0517 Email: hama@iastate.edu Department: ELECTRICAL ENGINEERING Univ Address: 4105 11TH ST City/State: DES MOINES IA 50313 Home City/State: DES MOINES IA Classification: SENIOR ----------------------------------------

55

---------------------------------------- Name: NGUYEN HUY TUONG Phone: 515-451-6072 Email: htnguyen@iastate.edu Department: ELECTRICAL ENGINEERING Univ Address: 1108 4TH ST APT #13 City/State: AMES IA 50010 Home City/State: SIOUX CITY IA Classification: SENIOR ----------------------------------------

---------------------------------------- Name: RASMUSSEN JUSTIN MICHAEL Email: jras@iastate.edu Department: COMPUTER ENGINEERING 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: STAAB DAVID ALAN Phone: 515-451-7817 Email: dstaab@iastate.edu Department: ELECTRICAL ENGINEERING Univ Address: 203 CAMPUS AVE #9 City/State: AMES IA 50014 Home City/State: COLWICH KS 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 ----------------------------------------

56

---------------------------------------- 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.4 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 semester’s addition to the project has approached the design of OSCAR by focusing its efforts on increasing its functionality and fixing current problems in the design. OSCAR is now ready for significant demonstrations of his abilities. Though the project was near-death at the beginning of the semester, an incredible amount of work has been put into bringing it back. Documentation has been laid down for future semesters which describes every important portion of the robot and allows future teams to come in with an understanding of the robot before they start working with it. Further, the Project Plan and Project Status Report documents have been completely rewritten, as the work from previous semesters either misunderstood or ignored the guidelines for these documents as published in the course notes. This semester’s work has left a foundation upon which all future semesters can build.

57

4.5 ReferencesThis subsection presents the sources used during research of the navigation algorithm.

Fuzzy Logic Tutorial – An IntroductionSteven D. Kaehlerhttp://www.seattlerobotics.org/encoder/mar98/fuz/flindex.html

Does a navigation algorithm have to use Kalman filter?Petr Vanìcek and Mensur Omerbašic, University of New Bruswickhttp://gge.unb.ca/Research/GeodesyGroup/members/VanicekOmerbasic.PDF

The Integration of an Optimised Fuzzy Logic Navigation Algorithm into a Semi-Autonomous Robot Control System. P. Webb, C. Fayad and C. Brettenbach, School Of Mechanical, Materials, Manufacturing, Engineering and Management, The University of Nottingham.University Park, Nottingham, NG7 2RD

A New Range-Sensor Based Globally Convergent Navigation Algorithm for Mobile Robots.Ishay Kamon, Elon Rimon, Ehud Rivlinhttp://citeseer.ist.psu.edu/kamon96new.html

Autonomous Navigation and Map building Using Laser Range Sensors in Outdoor Applications.Jose Guivant, Eduardo Nebot and Stephan BaikerAustralian Centre for Field RoboticsDepartment of Mechanical and Mechatronic EngineeringThe University of Sydney, NSW 2006, Australiahttp://www.cas.kth.se/SLAM/Papers/slam_robotics.pdf

Sensorial and Navigation Systems for a Mobile Robot (ROGER).Pere Ridao, Josep Forest, Lluís Pacheco, Xavier CufíComputer Vision and Robotics GroupInstitute of Informatics and Applications University of Girona.

58

4.6 AppendicesThis section contains relevant diagrams and tables explaining portions of Project OSCAR’s functionality.

4.6.1 Power System User’s ManualThe robot’s power system is controlled, accessed, and monitored via external interface panels built around the lower chassis. The panels are shown and explained in the following photographs:

Figure 4.28 : Power interface panel 1

Object Function1 Primary power switch Connects the power source to all electrical systems2 Power indicator lamp Lit when power is supplied to the robot by the battery3 Drive motor fuse Safety fuse for motor controller electronics (250 mA)

A

Object Function1 Recharge terminals Supply power to battery from battery charger2 Tri-Metric display Display current battery status*3 Tri-Metric fuse Safety fuse for Tri-Metric display (2 A)

* For more information on the operation of the Tri-Metric display, including instructions for setup and reading the display, see the Tri-Metric TM-2020 User’s Manual. This can be found on the Bogart Engineering website at www.bogartengineering.com.

Figure 4.30 : Power interface panel 3

Figure 4.29 : Power interface panel 2

B

Object Function1 Power inverter fuse Safety fuse for power inverter (30 A)

Robot power on / offThe robot power switch controls the primary power flow to all electrical components. When turned on, the power indicator lamp is lit and current will flow from the battery to all connected components. When off, the lamp is unlit, and the battery will be disconnected from all components (i.e. no current will flow).

Keep in mind that components, such as the computer system, may have their own power switches that will need to be pressed or toggled after the robot power switch has been turned on.

Battery rechargeA Sears 10/2 Amp Fully Automatic 12-Volt automotive battery charger has been modified with color-coordinated banana plug connectors that will interface directly with the recharge terminals

To charge the battery:1. Turn off the robot power switch (to protect electrical system components)2. Connect the banana plug connectors to the recharge terminals (red-to-red, black-to-black)3. Plug in the battery charger4. Set the battery charger to “Automatic Deep-cycle” and “2 Amp Rate”.

Warning: Do not charge the battery longer than 6 hours!(For more information regarding battery recharge, see the Optima D34/78 Specification Sheet in

Appendix 4.6.2 of the Fall 2004 Status Report document.)

C

4.6.2 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

D

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.

E

4.6.3 Selected specifications of RoboteQ AX2500 motor controllerThe following diagrams were taken from the user’s manual for the RoboteQ AX2500 motor controller. They functionally describe the electrical pin-out connections to the computer system.

Figure 4.31 : RoboteQ serial pin locationsFigure 4.32 : RoboteQ serial connection wiring

diagram

Figure 4.33 : RoboteQ serial signal-to-pin assignments

F

4.6.4 US Digital S1-256-B optical encoder specificationsPhysical and mechanical diagrams of the US Digital S1 series optical encoder are seen in Figure4.34 and Figure 4.35 below.

Figure 4.34 : US Digital S1 optical encoder

Figure 4.35 : Mechanical drawing of US Digital S1 optical encoder

G

The following tabulated specifications describe the US Digital model S1-256-B optical encoders found on the drive train system. All information was taken directly from the specifications given on the product page at http://www.usdigital.com.

Table 4.25 : Optical encoder mechanical specifications

Specification ValueAcceleration 250,000 rad/sec²Vibration 20 g. 5 to 2KHzShaft Speed 10,000 RPM max. continuousShaft Rotation -Shaft Torque 0.05 in. oz. Shaft Loading 1 lb. max.

Bearing Life (40/P)³ = life in millions of revs.where P = radial load in pounds

Weight 0.7 oz.Shaft Runout 0.0015 T.I.R. max.

Table 4.26 : Optical encoder mounting specifications

Specification ValueHole Diameter 0.375 in. +0.005 - 0Panel Thickness 0.125 in. max.Panel Nut Max. Torque 20 in.-lbs.

Table 4.27 : Optical encoder electrical pin-out

Pin Description1 Ground2 Index3 A channel4 +5VDC power5 B channel

H

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

Table 4.28 : 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)  

I

4.6.6 SONAR array schematicsThe following sections provide schematics for the 6500-series ranging module and the BX-24 microcontroller.

4.6.6.1 6500-series ranging module

Figure 4.36 : 6500-series ranging module schematic

J

4.6.6.2 BX-24 microcontroller

Figure 4.37 : BX-24 microcontroller schematic

K

4.6.7 Documentation of codeThe following sections describe all Java code written for the end product this semester. The reports were generated using Javadoc.

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

L

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

M

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            

N

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

O

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

P

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.

Q

static void main(java.lang.String[] args)           Listen for and execute commands.

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()           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.6.7.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 sp

R

Serial            private

longtimeout            

 

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)

S

          Enable or disable the eStop button. 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.

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

T

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

           private  int argY

           private

java.lang.Stringcommand            

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

U

           

 

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()           Continously run the last valid command.

private void

runCommand()           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.6.7.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.

V

Author: Zachary Kotlarek

Field Summaryprivate int[]

amps            

private long

ampsUpdate            

private int[]

analog            

private long

analogUpdate            

private int

angle            

private static long

defaultPollInterval            

private static long

defaultPollTimeout            

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 power

W

int[]            private

longpowerUpdate            

private static int

speedScaler            

 

Constructor SummaryMotionReader(Motion mot)           Generic constructor.

 

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 setAnalog(int ana1, int ana2)

X

void           Update the stored analog input readingsprivate

voidsetDigital(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.

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

Y

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            

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            

Z

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 static java.lang.Strin

g

outputLogTag            

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()

AA

          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.

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

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

Field Summary Serial sp

           

 

Constructor Summary

BB

Sensors(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.6.7.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.

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

CC

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            

 

Constructor SummarySerial()

DD

          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.

 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)

EE

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

 

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

FF

 

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.

GG

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

HH