Ongo01: Project OSCAR Spring 2005 Status Report Client: Iowa State University, Department of Electrical and Computer Engineering Faculty Advisor: Prof. Ralph E. Patterson III Team Members: Kevin Cantu EE 491 Philip Derr EE 491 Jawad Haider EE 491 David Hawley Cpr E 492 Zachary Kotlarek Cpr E 492 Michael Larson EE 492 Jeff Parent CprE 491 Justin Rasmussen Cpr E 492 Gavin Ripley Cpr E 492 Peter Rufino EE 492 Jason Sytsma EE 492 Lynn Tweed ME 466 David Willis ME 466 Report Disclaimer Notice:
Transcript
Ongo01: Project OSCAR
Spring 2005 Status ReportClient:
Iowa State University,Department of Electrical and Computer Engineering
Faculty Advisor:Prof. Ralph E. Patterson III
Team Members:
Kevin Cantu EE 491Philip Derr EE 491Jawad Haider EE 491David Hawley Cpr E 492Zachary Kotlarek Cpr E 492Michael Larson EE 492Jeff Parent CprE 491Justin Rasmussen Cpr E 492Gavin Ripley Cpr E 492Peter Rufino EE 492Jason Sytsma EE 492Lynn Tweed ME 466David Willis 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.
1 April 2005
ii
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.......................................................................................21.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...................................................................................4
1.5 Assumptions and Limitations..........................................................................................41.5.1 Assumptions............................................................................................................41.5.2 Limitations...............................................................................................................5
1.6 Expected End Product and Other Deliverables...............................................................52 Project Accomplishments and Current Status.........................................................................6
2.1 Previous accomplishments...............................................................................................62.2 Present accomplishments.................................................................................................82.3 Required future activities...............................................................................................122.4 Current project and end product status..........................................................................13
2.4.1.2.1 Sensor Software...........................................................................................142.4.1.2.2 Speech-based Command Input....................................................................142.4.1.2.3 Control Infrastructure..................................................................................152.4.1.2.4 GUI..............................................................................................................15
2.4.1.2.4.1 Multi-threaded communication system................................................152.4.1.2.4.2 Script system.........................................................................................162.4.1.2.4.3 New OSCAR commands......................................................................17
2.4.2 Sensor System........................................................................................................172.4.2.1 Current Status....................................................................................................17
2.4.3 Electromechanical System.....................................................................................172.4.3.1 Power System....................................................................................................172.4.3.2 End Effector.......................................................................................................172.4.3.3 Drive System.....................................................................................................17
i
2.4.3.3.1 Design..........................................................................................................182.5 Recommendation for continued effort...........................................................................18
3 Documentation of current efforts and results........................................................................203.1 Project definition activities............................................................................................203.2 Research activities.........................................................................................................20
3.2.1 Speech recognition selection.................................................................................203.2.2 End effector control selection................................................................................21
4.1.1 What went well......................................................................................................364.1.2 What did not go well..............................................................................................364.1.3 What technical knowledge was gained..................................................................364.1.4 What non-technical knowledge was gained..........................................................374.1.5 What would be done differently if you could do it over again..............................37
4.2 Risk and Risk Management...........................................................................................374.2.1 Anticipated potential risks and their management.................................................38
4.2.1.1 High-Level Risks...............................................................................................384.2.1.1.1 Ordered parts do not arrive on time.............................................................384.2.1.1.2 Equipment failure........................................................................................38
4.2.1.2 Medium-Level Risks.........................................................................................384.2.1.2.1 Failure to complete assigned tasks..............................................................384.2.1.2.2 Cost of development exceeds expectations.................................................384.2.1.2.3 Machining tragedy.......................................................................................38
4.2.1.3 Low-Level Risks................................................................................................394.2.1.3.1 Failure to attend a meeting..........................................................................39
ii
4.2.1.3.2 Software testing shows bugs in code...........................................................394.2.2 Anticipated risks encountered and success in their management..........................39
4.2.2.1 Ordered parts do not arrive on time...................................................................394.2.2.2 Software testing shows bugs in code.................................................................394.2.2.3 Failure to attend a meeting................................................................................39
4.2.3 Unanticipated risks encountered and attempts to manage them............................404.2.4 Resultant changes in risk management because of unanticipated risks.................40
4.3 Project Team Information..............................................................................................404.3.1 Client information..................................................................................................404.3.2 Faculty advisor information...................................................................................404.3.3 Student team information......................................................................................41
4.5.1 Power System User’s Manual.................................................................................A4.5.2 Specifications for potential end effector control solutions.....................................D4.5.3 Optima D34/78 battery specifications....................................................................H4.5.4 Selected specifications of RoboteQ AX2500 motor controller................................J4.5.5 US Digital S1-256-B optical encoder specifications..............................................K4.5.6 Robot Area of Detection........................................................................................M4.5.7 D-Link DWL-122 Specifications............................................................................N4.5.8 SONAR array schematics.......................................................................................O
List of FiguresFigure 2-1: New multi-threaded GUI structure.............................................................................16Figure 2-2: Wheel Tachometer circuit design..............................................................................18Figure 3-1: Path of robot motion...................................................................................................22Figure 3-2: Robot motion formulas...............................................................................................23Figure 3-3: Wheel tachometer software input screen....................................................................23Figure 3-4: Wheel tachometer software output screen..................................................................24Figure 3-5: Wheel tachometer turning algorithm input screen......................................................24Figure 3-6: Wheel tachometer turning algorithm output screen....................................................25Figure 3-7: Transducer range.........................................................................................................28Figure 3-8 : Actual project schedule 1...........................................................................................34Figure 3-9 : Deliverable schedule..................................................................................................35Figure 4-1 : Power interface panel 1...............................................................................................AFigure 4-2: Power interface panel 2................................................................................................BFigure 4-3 : Power interface panel 3...............................................................................................BFigure 4-4 : NMOS H-Bridge Circuit Design Schematic...............................................................DFigure 4-5 : PMOS/NMOS H-Bridge Circuit Design Schematic...................................................EFigure 4-6 : Specification for LM629 chip......................................................................................FFigure 4-7 : Specification for LT1158 chip....................................................................................GFigure 4-8 : RoboteQ serial pin locations........................................................................................JFigure 4-9 : RoboteQ serial connection wiring diagram..................................................................JFigure 4-10 : RoboteQ serial signal-to-pin assignments..................................................................JFigure 4-11 : US Digital S1 optical encoder...................................................................................KFigure 4-12 : Mechanical drawing of US Digital S1 optical encoder............................................KFigure 4-13: Area of detection using all eight SONARs...............................................................MFigure 4-14 : 6500-series ranging module schematic.....................................................................OFigure 4-15: BX-24 microcontroller schematic..............................................................................P
i
List of TablesTable 3-1: Formula variable key....................................................................................................22Table 3-2: Transducer status and repairs.......................................................................................25Table 3-3: Multiplexer testing results (x = no response)...............................................................27Table 3-4: Task description reference chart..................................................................................29Table 3-5 : Estimated personnel requirement 1.............................................................................30Table 3-6 : Estimated personnel requirement 2.............................................................................30Table 3-7 : Actual personnel requirement 1..................................................................................31Table 3-8 : Actual personnel requirement 2..................................................................................31Table 3-9 : Estimated financial requirements................................................................................32Table 3-10 : Actual financial requirements...................................................................................33Table 4-1 : Optical encoder mechanical specifications...................................................................LTable 4-2: Optical encoder mounting specifications.......................................................................LTable 4-3 : Optical encoder electrical pin-out.................................................................................LTable 4-4 : D-Link DWL-122 Specifications.................................................................................N
ii
List of Symbolso Degrees
® Trademark restriction applies
§ Section reference
iii
List of DefinitionsAC Alternating current
Ball and roller bearings Cup and race constructing bearings with rollers or balls between cup and race
CAD Computer-aided design software
Composite bushing A self-lubricating linear bearing lined with plastic
COSMOSWorks Finite element analysis software by the SolidWorks Corporation
CPU Central processing unit
CVS Concurrent Versions System
DC Direct current
DC/DC converter A device that is placed between an electrical power source and its load. The unit changes the source voltage to a useable level for the load.
Deep-cycle A type of rechargeable battery that can be almost completely drained before it must be recharged.
Drive train The assembly of electrically controlled motion elements, including the robot’s wheels, gears, belts, and tachometers
EBay® http://www.ebay.com, an auction website
End effector The assembly of electrically controlled mechanical arm and gripper
Ethernet A widely used computer network communication protocol
GUI Graphical user interface
H-Bridge A circuit diagram which resembles the letter "H." The load is the horizontal line, connected between two pairs of intersecting lines. It is used to control the direction of current flow, and thus the rotational direction of the motor.
Iglide® A bushing produced by the igus® corporation
Javadoc® A code commenting system designed by Sun Microsystems®
Kevlar® A polymer made by DuPont®
LabView A development tool written by National Instruments® for use in programming instrumentation
Linear bearing A rolling element that moves on a straight track
Radio Ethernet A method of utilizing the Ethernet protocol over radio frequencies
RAM Random-access memory
RPM Revolutions per minute. The number of complete rotations of the wheel in one minute.
iv
Runout Movement from side to side
SAE Society of Automotive Engineers
Serial radio link A method of sending sequential information between networked computers over radio frequencies
Servo gearmotor Electric motor used to control components
Solidworks® A CAD program developed by the Solidworks Corporation
SONAR Sound navigation and ranging
Super Grip® Rubber coating made by the Plastech® Company
Tachometer A device for indicating speed of rotation from the wheels
Troubleshoot Assess and amend problems that arise during the engineering process
Wrought material Pre-machined stock material
v
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. A new design has been completed and is awaiting implementation. 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. A wireless setup has been implemented that allows control from a remote PC. Robot control is further simplified by being implemented through software with a graphical user interface. This leads up to the current condition of the robot, which will be discussed in the next section.
1
ripoff1, 03/30/05,
Updated – GR Needs proofreading
1.1.4 Current AccomplishmentsThe main goals of this semester are to repair the SONAR array, install the wheel tachometers, implement speech control, extend upon the existing control software, and implement the end effector design. SONARs are now providing distance readings, but an inability to multiplex the data from all eight SONARs simultaneously has hindered full completion. The implementation of a circuit to link the motor controller and wheel tachometers is nearly complete as a parts shipment has just arrived upon the creating of this document. Software to use the data from the wheel tachometers to calculate distance and orientation has also been designed and implemented. Software used for speech recognition has been chosen and implemented into the robot and a microphone has also been installed. The GUI control software has been updated to a more versatile multi-threaded system and also allows for scripting capabilities to let the user record and replay a list of commands. Currently, end effector implementation is just beginning as our mechanical engineers have just recently joined the team. The end effector controller design is also beginning, but a likely circuit layout has already been determined. There is quite a bit of work to be done, which will be discussed in the next section.
1.1.5 Work To Be CompletedOnce some key tasks are completed, the status of the robot will advance significantly. A working SONAR ring will provide for a much more flexible control system because collisions would be preventable. A new multiplexer will have to be implemented in order to gather data from all eight SONARs simultaneously since it is doubtful that the current multiplexer in the circuit is working correctly. This will involve either obtaining a programmable multiplexer or implementing a new one through circuitry. A new layer of control also needs to be added to the software so that the robot can be controlled manually, by speech, or be interrupted by a SONAR detected collision, all concurrently. The wheel tachometer circuit still needs to be built and connected to the motor controller so that it can tested. Then, the wheel tachometer software can be modified to properly use the data sent from the wheel tachometers. To further the progress of the end effector, the models previously designed need to be converted to detailed drawings that can actually be built. Once this is done, a bill of materials for the end effector can be created so that materials not currently in the team’s possession can be identified and obtained. These two things will ease the process of fabricating and assembling the different components of the end effector. A detailed design for implementing a controller for the end effector will also be completed so that it can be implemented and control software can be written for it next semester.
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
2
ripoff1, 03/30/05,
Updated -GR
ripoff1, 03/30/05,
Updated –GR
ripoff1, 03/30/05,
Updated –GR
the robot’s speed and direction. Similarly, the sensor array needs to be able to communicate with the computer so that objects present in the robot’s surroundings can be interpreted and avoided. The robot needs a device that will be capable of manipulating objects in its surroundings. The device, known as the end effector, 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. As an alternate method of operation, the robot must also be able to be controlled by spoken commands. All onboard software must communicate with a specified remote PC so that no cables need be attached. A logical approach to resolving these problems is discussed next.
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. A power inverter will be chosen that will be capable of powering the computer for extended periods of time. To move the robot, a motor controller will be chosen that can interface with wheel motors, wheel tachometers, and 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 each SONAR transducer. A retractable end effector will be designed and manufactured with simplicity and versatility in mind. A controller capable of interacting with the end effector motors and computer must be built for this component as well. For optimal stability, a robust software system will be written in Java and installed on the robot. Existing speech recognition software will be chosen and implemented with the robot’s software system. 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.
1.3 Operating EnvironmentThe end product shall operate in the following, controlled environments:
A typical classroom setting or under ideal (no rain, 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.
3
ripoff1, 03/30/05,
Updated -GR
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 autonomously navigate a hallway 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.
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 must be proficient 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. Prior to operating, any operator of the end product shall be informed how to use the
control software. To control the robot during presentations, the operator shall have a wireless USB adapter
and a Windows PC with the control software installed. The battery has been fully charged before demonstrations. The battery shall only be used to supply power to the motion control components,
onboard computer, speakers, sensory array, and end effector. The current drive train control unit is fully functional. The existing computer hardware is fully functional to handle existing computing loads. The sensor 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.
4
ripoff1, 03/30/05,
Updated -GR
ripoff1, 03/30/05,
Updated -GR
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-14 : D-Link DWL-122 Specifications). Under a full battery charge, the robot shall not remain in operation for more than one
hour. Spoken commands are executed from no more than 20 feet away. Recognized speech patterns shall not exceed twenty commands to limit processor load. All systems must reside within in the robot’s chassis. The width of the chassis is fixed at 30 inches.
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
5
ripoff1, 03/30/05,
Updated -GR
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.
6
Spring 2003: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.
7
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.
Fall 2004:o Reference material for the SONAR array was created.o SONAR testing from Spring 2004 was documented, however, it was discovered
that the controller program was not working. o DC/DC converter solutions were considered and determined to be too costly to
purchase on a senior design budget. o The drive train subsystem was repaired to eliminate belt slippage.o The wiring in the lower module was completely removed and replaced. New
wiring was implemented according to necessary current and future use cases. Fuses and recharging connections were made available externally.
o A new end effector was designed and modeled for future implementation.o Control solutions for the end effector were considered.o Existing software was significantly overhauled. A new control infrastructure was
developed for the robot’s software. Sensor software was not written as they were not functional at the time.
o A remote interface was developed to allow the robot to be controlled via a wireless connection.
o A GUI was written to provide an easier method of control.o The new wiring system, software control structure, code, and end effector design
were appropriately documented.o A façade was built and installed.
With many commercial and free speech recognition software choices available, a logical selection needed to be made that would best fit the project. Software that can recognize pre-recorded utterances was selected because it required the fewest amount of computational resources and would be least likely to interfere with concurrent computer processes. CVoiceControl, a free Linux version of this type of speech recognition software was chosen and installed on the robot.
Select I/O interface for end effector control Completion: 100%Since the decision was made to build a custom control circuit for the end effector, a serial port I/O interface was chosen. This method will allow for software to be developed with little difficulty. A serial port card or USB to serial adapter will have to be obtained once the control circuit is built because there are not any ports currently available on the computer. A PCI motor control card from National Instruments was also considered, but was not chosen for reasons discussed in the following.
Consider end effector control solutions Completion: 100%Much research was done to determine if end effector could use LabView and other products developed by National Instruments for a method of control. The technology was certainly available, but would require two computing demands that were not feasible for this semester. One was obtaining a new computer system. This was attempted by seeking
8
ripoff1, 04/01/05,
Updated –GR
ripoff1, 03/30/05,
Updated –JR/GR
donation, but has not materialized as of now. The other would have required the complex task of writing drivers to support the National Instruments motor control cards. Instead of using National Instruments parts, a control circuit will be assembled using a LM626 microcontroller and an H-bridge.
Consider end effector hardware solutions Completion: 25%Since mechanical engineering support did not arrive until the latter part of the semester, this task is currently in development. All usable materials will be gathered and set aside for implementation. By the end of the semester, a detailed bill of materials will be completed that will outline what materials are currently available to the team and what materials need to be obtained and their prices.
Consider purchase of DC/AC inverter Completion: 100%This task was initially put on hold until power specifications for a new computer system arrived. Since this has not happened, it was determined that it would be beneficial to upgrade the current power inverter to one that would supply more wattage. This was determined to be necessary because the current inverter has had problems overheating when used for multiple presentations.
Design wheel tachometer circuit Completion: 100%The circuit to give usable data to the motor controller from the wheel tachometers is completely designed. The design involves reading the frequency output of the wheel tachometers and converting the signal to a voltage that the motor controller can use. All components of the circuit were identified and ordered.
Design software to interact with wheel tachometers Completion: 100%A reliable method of using data from the wheel tachometers needed to be researched and designed. The design involved using the wheel speed data to estimate distance traveled, degrees turned, and the x, y coordinate position of the robot, all relative to the starting position. The design was done by using a few important trigonometric functions.
Develop navigation algorithm Completion: 15%Design of successful robot navigation involves the integration of many different disciplines, among them kinematics, signal analysis, information theory, artificial intelligence, and probability theory. This is still in the early stages of research and finding sources and papers that teach us more about the constraints and requirements that will be dealt with.
Design end effector controller Completion: 25%A simple design is currently being developed for the end effector controller. Currently, the basic design will be to use a LM626 microcontroller connected with an H-Bridge. The H-Bridge will control the motor direction and the microcontroller will interface everything together with the onboard computer. All design updates will be included in an updated version of this report.
Implement speech recognition Completion: 75%The initial work on this task involved obtaining a reliable microphone that could detect audio surrounding the robot. A microphone with a pre-amplifier circuit on it was rewired to work with the current audio input. Since the selected speech recognition software was not Java based, a device was written so that the speech recognition could relay commands to a file that the Java software could concurrently read from. Remaining work involves adding a top layer to the software structure so that the robot can be controlled by speech commands, keyboard entries, and SONAR interruptions simultaneously.
9
Extend existing GUI software Completion: 75%The existing GUI needed additional work to add functionality and improve the performance of the existing software. To accomplish this goal a multi-threaded network layer was designed for use in the GUI. This improved performance by allowing the GUI to remain responsive while waiting for the robot to respond. To support added functionality of the software running on the robot, events were added to the GUI’s network layer. These events make it easier to add new commands that may be supported by the robot as well as allowing a scripting system to be built.
Implement wheel tachometer circuit Completion: 75%The completion of this task was hindered by parts being lost during delivery. However, the parts have recently arrived and are currently being added into the circuit and tested. When everything operates as designed, two circuits will be built and connections will be soldered for each wheel tachometer.
Implement software to interact with wheel tachometers Completion: 85%Initial implementation has involved modeling the robot in its own Java class because actual wheel tachometer data is not yet available. The software accepted independent wheel speeds as input and used that data to calculate distance traveled, turning degree, and the x, y coordinate position. All of these outputs are relative to the robots starting position and were calculated over a preset time period. The remainder of the work for this task will be to modify the software to use data from the actual wheel tachometers as soon as they are installed.
Install wheel tachometers Completion: 0%Once the wheel tachometer circuits are completely assembled, each circuit will be secured in a metal casing. The wheel tachometer outputs will be connected to the respective circuit, and in turn, connected to the motor controller. The robot should then be set up for wheel speed readings.
Repair SONAR array Completion: 75%The beginning of the repair process required testing of the continuity of all interconnections from transducer to BX24 and from BX24 to the PC. A test signal was put through each transducer and SONAR array module with a 15 Hz, 3Vpp square wave and the corresponding wave forms were measured to compare the INIT and ECHO. The time delay between the two signals was measurable, which verified that the hardware was functioning properly. Next, new SONAR software was successfully downloaded to the BX24. The software worked with I/O pin 8 and 9 of the BX24 and a transducer on a breadboard setup. After this successful test, the BX24 was installed on the SONAR PCB. The results were sporadic output from all of the transducers which indicated that the multiplexer was not functioning correctly. After testing the multiplexer in an isolated environment, it was determined that the three select pins of the multiplexer did not correspond to the connections required by the SONAR PCB. A new PEEL has been procured and the fuse map has been laid out for a multiplexer with the same functionality.
Implement new end effector Completion: 0%There are a couple issues that have delayed the implementation of the end effector. First, the mechanical engineers have not begun development until just recently due to a lack of
10
resources from that department. Second, the detailed design developed last semester contains models of the components of the end effector. The models need to be converted into detailed drawings that can be physically built. Because of these hindrances, actual implementation will likely be delayed until next semester. By the end of the semester, the detailed drawings will be ready for implementation and all materials will be collected and itemized.
Characterize SONAR array Completion: 40%The SONAR array has currently been characterized on the horizontal axis. The characterization began by isolating one transducer with 30 ft of open environment to gather data. The room length was approximately 30 ft which enabled testing of the high range of the transducers specifications. Beginning at a distance of 3 feet in front of the transducer and far to one side, an object was moved closer to the transducer in a perpendicular line to the SONARs view. When it was clear that the reading signaled the object was in sight, the position was marked and the 3 ft forward distance was increased. This procedure was continued till the high end range was met. Using this data, a visual map was created through extrapolation.
Test newly developed software Completion: 25%All of the newly-developed software has been tested and found to conform to the established requirements. The multithreading addition to the GUI was tested to verify that multiple threads could read and write to the network without corruption of data or locks. Output from the wheel tachometer software was checked against known values to ensure accuracy. The accuracy of the speech recognition software was tested by speaking known commands and ensuring a response from the system. All testing done in detail will be expanded upon in the testing activities section.
Automate software testing Completion: 0%Automated software testing has not had a high priority for completion as of yet. By the end of the semester, automated tests need to be developed in order to facilitate the augmentation of software. Once complete, changes to the robot's core software can be easily verified against the expected operation without extended manual testing.
Test new end effector Completion: 0%Testing of the end effector assembly has not yet begun because it will doubtfully be implemented this semester. Testing will be conducted once the end effector has been fully assembled.
Document wheel tachometer circuit Completion: 100%The circuit required to implement the wheel tachometers has been documented so that further teams can recreate the circuit should it begin to malfunction due to age or wear and tear. This should eliminate the chance of having to duplicate the design work further down the road. Furthermore, should future teams be required to add functionality to this section, they will not have to reverse engineer it.
Document newly developed software Completion: 100%All newly-developed software has been documented so that further teams can build on the progress made this semester. Since the software has been written using the Javadoc standard and stored in a CVS repository, the documentation can be compiled at any time into a single file.
11
Document end effector controller design Completion: 25%The work done on the end effector controller design is currently in progress and is being documented as it progresses. The final documentation of the end effector controller will be included in this report at the end of this semester so that future teams have it at hand.
Present robot to campus visitors Completion: 0%The robot has not yet been presented to any campus visitors, as no visits were scheduled prior to the compilation of this document. However, four presentations are scheduled in the upcoming weeks and this portion of the document will then be updated to reflect those results.
Develop scripts and macros for demonstrations Completion: 0%Scripts and macros for demonstrations have not yet been developed, as this task has been delayed partially by the sensor troubles and also because of its overall low priority. This task is dependent slightly on the sensors so that the demonstrations can be written to take advantage of the sensor behavior; however, in the case that sensors still aren’t working at the beginning of demonstrations, they will be done via manual control.
2.3 Required future activities Implement and test end effector Fall 2005
With the design completed in Fall 2004, the end effector was theoretically ready to be assembled; however, because mechanical engineers did not begin work until late in the semester, the implementation has been delayed. Furthermore, it has been found that the design models from Fall 2004 needed to be converted to drawings that could be physically built. Many of the motors from the original arm are still included in the new design, and any other materials that can be salvaged from the original arm will also be used. Other needed materials will be researched and purchased or machined accordingly. Once built, the end effector will be installed on the upper layer of the robot as per the overall design.
Implement end effector control circuits Fall 2005Circuit boards for end effector motor control must be built according to designs created during this semester and installed appropriately.
Develop end effector control software Fall ‘05 – Spring ‘06When 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 ‘05 – Spring ‘06A 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
12
the time for this task. As the sensors are expected to be fully functional by the end of the semester, this task should be completed in the fall.
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. This will obviously be a low priority until the end effector itself is implemented and installed.
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 currently have taken place in the overall design or appearance of the robot, though it is possible significant changes may take place in the near future. These changes include:
As part of the robot's speech recognition system, a microphone was necessary to provide audio input. While suitable microphones for such system were readily available, specifications required an amplification system for the microphone so that the robot could be commanded from a distance without unnecessary vocal strain. To that end, a line-level audio pre-amp circuit was obtained and combined with a standard microphone and various connectors to provide compatibility with the robot's existing audio input and power interfaces.
The replacement of the entire computer hardware. This will eventually be necessary in light of the demands being made on the robot by its current software. Should extension of that software occur under future teams, as it likely will, the current hardware may not be sufficient. New hardware was expected this semester; however, the donor has apparently left the country on business and the hardware is not currently available.
Other changes to the hardware are unlikely to be made this semester, as it is possible to finish implementation of this semester’s goals without them.
2.4.1.2 SoftwareSince working SONARs are expected by the end of the semester, sensory software has currently begun development. The addition of speech recognition software has been completed and is awaiting a detailed command set. As a result of these new additions, a new layer of control is being added to the software in order to handle speech control, manual control, and SONAR interruption simultaneously. The GUI has also been expanded to become multi-threaded and allow for scripting capabilities.
2.4.1.2.1 Sensor Software
13
ripoff1, 04/01/05,
Updated –JR/GR
A good baseline for the sensor controller software was found in the sample code provided by its manufacturer, but it only allowed for the testing of one single transducer. This made it necessary to expand the code to fit into the current implementation of the array. Because of problems with the multiplexer on the circuit, testing of the expanded code has not currently been completed, but it is expected that this will take place inside the next week. This document will then be updated to reflect the new status of the controller software.
Another facet of the sensor software is that it is located on the robot as part of the control infrastructure. This portion has also been implemented, but without working sensors it is difficult to determine its functionality further than simply compiling it. Once the multiplexer in the sensor array has been repaired, this will be tested by outputting the recorded distances into the console and determining whether they match those reported by the sensors. Further testing will need to be done as this portion of the software fulfills control infrastructure goals. This will be documented in the next section. Once testing takes place, this document will be updated to reflect the results.
2.4.1.2.2 Speech-based Command InputThe existing control infrastructure provides command access from only one source at a time. Given the previous limitations of the robot this design was sensible, but it does not allow for the simultaneous use of speech and keyboard or script-based commands. The first stage of speech-based command implementation therefore must be to allow multiple simultaneous command sources.
After the control infrastructure is modified to accept speech and keyboard-based commands, the utterance recognition software must be interfaced to the existing control infrastructure. This process is complicated by the fact that the utterance recognition software is not Java-based and therefore does not provide native interfaces to the robot's control infrastructure. This interface will therefore consist primarily of a Java program which accepts input from the utterance recognition software and simulates keyboard-based commands with respect to that input.
After a discussion of methods of multi-process communication, a basic data and lock file scheme was decided upon. To this end, a device driver for the Linux operating system currently running on OSCAR was developed which allows the speech software to write to a device from one application and create a pipe to another application which would read the data. Both of these applications believe that they are reading and writing to a text file. This will solve the communications problems and do so via a very simple interface.
2.4.1.2.3 Control InfrastructureThe robot's existing control infrastructure provided good support for primitive commands but no support for feedback-based commands. For example, the robot could be commanded to move forward or to turn left, but had no facilities for more complicated commands like “move forward 10 feet and then stop”: such commands would require the user to estimate how long it will take to move the distance. However, these commands can be easily decomposed into their primitive components (i.e. “go forward”, “stop”), and after such decomposition can be easily executed using the existing command system.
14
The existing control infrastructure was designed to provide easy extensibility specifically for this purpose, and as such it will be relatively easy to insert a decomposition algorithm into the command infrastructure to provide complex command support. Combined with additions to the command protocol, which is similarly extensible, the robot will support complex commands for measured linear and angular motion as well as collision avoidance.
When wheel tachometers are in working order, the wheel speed data will be used as another method of control to issue commands like “move forward 10 feet,” as mentioned earlier. The software will poll data through the motor controller a few times every second. Distance, position, and orientation will be calculated on the fly and ready upon request.
Another important part of this functionality is provided by the sensor command class. This class provides the interface between the control infrastructure and the sensor array. As mentioned in the previous section, it is very difficult to test this component without a working sensor array, however, it is possible. One potential test would involve writing a piece of code which will occasionally return a value inside the collision radius. This would allow the control infrastructure to execute the portion of the code designed to handle collisions without actually using the sensors. Should the current problems with the sensors remain, either this or another suitable manner of testing the software will be developed and the results placed in this document.
2.4.1.2.4 GUIThe GUI associated with the project required some work to match that done on the rest of the software. This section details that portion of the work.
2.4.1.2.4.1 Multi-threaded communication systemThe communication system for the GUI has been converted to a multi-threaded event-driven system. It is now possible for several threads or objects to use and listen to the network without any modifications to the network layer. This allows the GUI to respond to unsolicited messages should they be added to the communication protocol. This system is currently in its testing stages and is expected to be completely finished within the week.
2.4.1.2.4.2 Script systemThe scripting system is nearly complete. Remaining work will primarily be spent testing after the multi-threaded communication system completes testing. The system in its implementation can be broken into three separate parts and is depicted in Figure 2-1:
The recording class, which is responsible for hooking into the network layer and capturing all network traffic. This class will then make sure that the message should be recording and send it to the persistence class.
15
ripoff1, 04/01/05,
Need to reference & explain figure inserted below
The persistence class, which is responsible for creating an object of all the commands sent to it by the recording class. Once the last command is sent the object with the list of commands, it will be serialized to the disk. The persistence class is also responsible for de-serializing a set of commands at the request of the playback class; and finally,
The playback class, which will work through the list of commands received from the persistence class. It will then replay the commands to the network layer just as if they had been generated from GUI events.
The scripting system is on schedule to be finished by the end of the semester, prior to the IRP.
Figure 2-1: New multi-threaded GUI structure
2.4.1.2.4.3 New OSCAR commandsThe software on OSCAR is being updated to support an extended command set. The GUI will support these commands once they are fully-defined. In preparation, skeleton code has been developed which will simply need the command words inserted. This will be done as the command set is enhanced.
16
2.4.2 Sensor SystemThe sensor system has remained the source of many schedule delays this semester.
2.4.2.1 Current StatusMost of the work done on the SONAR array this semester has been testing activities. First, each transducer and SONAR module was tested for functionality, then the SONAR demo program was loaded onto the BasicX chip and tested with a single transducer and SONAR module. All of the wiring in the array from each transducer to the BasicX chip was checked and documented, then all of the various connections in the SONAR array were also mapped out. These steps led to the discovery that the part causing the problems was the multiplexor. Once the multiplexer is replaced or fixed, the SONAR program using all eight transducers can be implemented on the BasicX chip for a fully functioning SONAR array. Fixing the multiplexer problems is taking longer than expected as no documentation of the part can be found from previous OSCAR teams (and a considerable amount of time was spent looking for them). In fact, the search for an instructor who can provide guidance in programming a new multiplexer is still underway, as nobody in the engineering college, including instructors, seem to know how to do it.
2.4.3 Electromechanical SystemThis section details some of the work done on the electromechanical system this semester.
2.4.3.1 Power SystemVery little work was needed on the power system this semester. A new, 400W inverter has been chosen and will be purchased to replace the currently-existing, 250W inverter by the end of next week. This document will then be updated to reflect these changes.
2.4.3.2 End EffectorThe mechanical engineers have only recently begun to work on the project, and consequently there has not been much work done fabricating the end effector. Currently, the design is being reviewed and drawings are being made from the models created last semester so that fabrication can take place.
2.4.3.3 Drive SystemThe main changes to the drive system this semester have been in the form of the wheel tachometers.
2.4.3.3.1 Design Optical Encoder: A sensor that translates mechanical motion into electrical signals. Phase Decoder: Decodes the phase of the signal into electrical signals. SPDT: a single-pole double-throw switch. F2V: Frequency-to-Voltage converter. DC Bias: applied to the control voltage output so that it is in the appropriate range for the
controller’s specifications.
17
ripoff1, 04/01/05,
Do we need to do this? Everything to tell is told in detail in present accomplishments? -GR
A new design for the wheel tachometer circuit has been created as shown in Figure 2-2. An optical encoder is connected to a phase decoder by two channels, A and B. Then a frequency-to-voltage converter is connected to the charge pump in order to channel the directional signal to the SPDT. It is regulated by DC Bias to control voltage output into the motor controller.
Figure 2-2: Wheel Tachometer circuit design
Currently, the Phase-to-Voltage converter and DC bias have been implemented and tested, but the phase decoder and SPDT switch have yet to implemented and integrated to the final design. After these parts are integrated, the circuit will be implemented and put on a PCB. Finally, two metal cases will be used to mount the two tachometer circuits on the robot. Unfortunately, the implementation of the circuit has been slightly delayed due to delays in receiving the parts.
The SPDT has just arrived as of the writing of this report, and as such it is expected to be added to the design within the following week. This document will be updated with the results of the testing of the circuit once this task reaches that phase.
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.
By its 9th 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 problem we continued 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
18
ripoff1, 04/01/05,
Needs update
their undergraduate curriculum. This is not to say that progress cannot be made or understanding cannot be obtained or mastered: rather, that in a two- or 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 perhaps the greatest challenge faced by OSCAR, and indeed by any ongoing team.
19
3 Documentation of current efforts and resultsIt is important that all research, design, implementation, and testing activities are regularly documented. A strong focus has been placed on creating high quality documentation that can be used as a reference and guide for future teams.
3.1 Project definition activitiesNot applicable.
3.2 Research activitiesThere were several tasks this semester that required some research to be done prior to design and implementation.
3.2.1 Speech recognition selectionIn order to fulfill the design requirements of the OSCAR project, a speech-based command system is necessary. While the complete speech command system contains many components, the system is largely constrained by the type and quality of initial speech recognition. There are many commercial and free implementations of speech recognition available, and they fall into three basic categories: continuous speech recognition, limited-vocabulary speech recognition and simple utterance recognition. The choice among these options was governed primarily by the relatively low computational capacity of the robot's computer.
Continuous speech recognition can transcribe complete sentences from a vocabulary of 100,000 or more words. This type of system allows users to phrase commands in their own words, making it the most flexible with respect to user interaction. Continuous speech recognition has drawbacks though, including very high computational demands and an extended "training" time, during which users must read a known text into the system. Given the limited resources of the computer system, continuous speech recognition is not currently an option.
Limited-vocabulary speech recognition is similar to continuous speech recognition, but limits users to a very small vocabulary, generally under 100 words or phrases. This limitation forces users to know pre-defined command sentences for the robot, but also greatly reduces the computational demands of the speech recognition process, and eliminates the need for "training." Limited-vocabulary speech recognition is likely feasible using the robot's current computer, but may interfere with time-sensitive operations, including navigation, and therefore is less preferable than other available options, but should be given new consideration if and when the robot's computer is replaced.
Simple utterance recognition is different from speech recognition in that the computer does not recognize and transcribe words, but simply compares incoming audio data to pre-recorded samples and identifies probably matches. This system requires not only that users issue pre-defined commands, but also that they pre-record samples of those commands. However, simple utterance recognition requires significantly fewer computational resources than other recognition system and therefore does not interfere with other operations even on the robot's current computer. As such, simple utterance recognition is the most desirable technology available at this time with respect to other project constraints.
20
ripoff1, 04/01/05,
Updated -GR
3.2.2 End effector control selectionMost of the research regarding controlling the end effector was done in order to determine if the robot could utilize certain products from National Instruments (NI). Having a system in the robot controlled by NI systems would be beneficial because of their on campus support and product quality. Most of this research was done by directly communicating with NI representatives and local knowledge bases.
Two concerns prevented the use of National Instruments’ hardware and software. One was using their motor controller PCI card and their LabView software on the current Linux operating system. Since NI does not offer Linux support, it was determined that a driver would either have to be purchased from a third party or have to be coded using a driver developer kit. Since LabView uses its own programming language, integrating it with the Java software structure would be complex and inefficient.
The other concern was the processing power required to run their equipment. Clearly, a new computer system would be necessary in order to efficiently run LabView and the rest of the robotic systems. It would not have been a problem, but a computer donation from Lockheed Martin has not come through as of now.
To better serve the existing computer system specifications and operating platform, a control solution will be developed that will use the LM626 microcontroller along with an H-bridge to control direction of the motors. However, this design is not completed at the time of this report and new information will be documented in future revisions. Documentation of this control solution can be found in the Appendix, Figure 4-15, Figure 4-16, and Figure 4-17.
3.3 Design activitiesSeveral design activities have taken place over the course of the semester. This section documents them.
3.3.1 Wheel tachometer softwareHaving the capability to read wheel speed data will allow for many new features to be added to the robot. Currently, all commands are given by sending “GO forward for X seconds” or “TURN for X seconds.” Wheel tachometer software will allow for distance and degree based commands to be sent. It can also notify the calling method when the robot has traveled a certain distance, so that it does not have to be checked routinely. The issue that the wheels can rotate in sync, out of sync, or in different directions creates some problems. A method to determine distance and degrees from orientation needs to be determined.
21
The software will work by reading the wheel tachometers a few times a second. During each reading the software will calculate the change in theta (θ), the change in x direction, the change in y direction. The change for each measurement will be added to existing data so that total distance, current theta (relative to orientation), and current X, Y position (relative to orientation) can be viewed. The orientation can be reset whenever needed. Figure 3-3 further explains this setup.
Figure 3-3: Path of robot motion
There are four main formulas that are used to calculate the needed data. One to calculate the change in theta, two to calculate the X, Y position, and one to calculate the change in distance. These formulas are given in Figure 3-4. Variable meanings are listed first, in Table 3-1. Details on how the software was implemented are provided in the next section
Table 3-1: Formula variable key
Symbol MeaningTimeInitial orientationRight wheel velocityLeft wheel velocityDistanceRobot widthInitial X coordinateInitial Y coordinate
22
Figure 3-4: Robot motion formulas
3.4 Implementation activitiesMuch of the work this semester deals with actual implementations. This section documents these.
3.4.1 Wheel tachometer software implementationBecause data from the wheel tachometers is not currently available, the robot was modeled in Java so that the formulas listed in the design could be tested and optimized. When wheel tachometers are operational, the software can be modified to use actual data. Two programs were written and will be explained below.
The main program lets the user enter both of the robot’s wheel speeds to do distance, theta, and X, Y coordinate calculations. The user also has the option of resetting the robot’s orientation by clicking reset. Units for wheel speed entry are feet per second. The input screen is shown in Figure 3-5. The corresponding output screen for a few data entries is then shown in Figure 3-6.
The other program written takes a degree as input and calculates the wheel speeds and time needed to turn that number of degrees. A negative degree indicates left from orientation, while a positive degree indicates right from orientation. Due to the speed of the motors, the minimum turning degree is ±10 degrees. The input screen is shown in Figure 3-7. The output screen for a few data entries is shown in Figure 3-8.
3.5 Testing and modification activitiesMost of the testing involved troubleshooting the SONAR array.
3.5.1 SONAR TestingMuch of the work on the sensor array was spent testing it to determine what portions were causing the malfunction.
3.5.1.1 Individual TransducersFirst, the transducers and SONAR modules were tested to see if they were working correctly. A function generator was used to send a 15Hz, 3Vpp signal to the INIT pin of the SONAR module. The module was powered by a 5V power supply, and the ECHO response was measured with an oscilloscope. A 4.7k ohm pull-up resistor was put between 5V and the ECHO pin. Transducers not behaving correctly were noted and then inspected for problems. All problems were caused by bad wiring connections. To repair them, some just needed tightening, while others needed to be re-soldered. The non-functioning transducers and problem corrections are listed in Table 3-2.
Table 3-2: Transducer status and repairs
Transducer Status Repair made0 fine1 fine None.
2 no responseConnecter between housing and transducer was loose.
3 fine None.4 fine None.
5 works but not very accurateConnection between transducer and cable that connects to the housing re-soldered.
6 stuck with full square wave for Connection from housing to array module re-
25
ripoff1, 04/01/05,
Updated –GR
ECHO response soldered.7 fine None.
3.5.1.2 SONAR Array ConnectionsA multi-meter was set up for fault detection. The multi-meter would emit a beep whenever two connected pins were found. The interconnections were traced and mapped out using this method. Specific transducer ECHO and INIT pins were mapped to the multiplexer and specific multiplexer pins were mapped to the Basic-X chip and the path of each individual input and output within the SONAR array.
3.5.1.3 Basic-X SONAR ProgramIn obtain actual distance readings, a SONAR testing program was downloaded to the Basic-X chip. The single transducer setup, described above, was used with INIT and ECHO connected to different I/O pins of the basic-x chip. The pins were set in the program, and the program was run. The program output was the distance in millimeters between the source and the object that the transducer was detecting. The distance detected seemed to be close to the actual distance of a test object, but the accuracy still needs to be tested more thoroughly.
3.5.1.4 MultiplexerWithout documentation, some assumptions had to be made in order to test the multiplexer. Through mapping the SONAR array connections, it was found that all of the ECHO and INIT pulses go to the multiplexer as well as five I/O pins from the basic-x chip. Two I/O pins of the basic-x chip were thought to be the pins that send INIT pulses and receive ECHO pulses. The other three I/O pins (which were also connected to the seven segment display) were thought to signal what transducer to interface. The multiplexer was tested by setting the INIT pin that went to the basic-x chip to 5V. Then all eight combinations were tried on the 3 signaling pins while the ECHO and INIT pins on the multiplexer that went to the transducers were tested with a multi-meter for each signaling combination. This process was repeated for the ECHO pin on the multiplexer that went to the basic-x chip. All pins that registered an appreciable voltage in testing were marked. The results of the test can be found in Table 3-3. All of the responses from the multiplexer were 2.5V. As an example, pin I5 stands for the multiplexer pin that goes to the INIT pin of the 5th SONAR module. Few INIT pins registered responses and no ECHO pins did. Also, the bit order is as it was on the multiplexer but seems out of order with what pin numbers it activated.
26
Table 3-3: Multiplexer testing results (x = no response)
Signal bits INIT Responses ECHO Responses0 0 0 x x0 0 1 I4 x0 1 0 x x0 1 1 I5 x1 0 0 x x1 0 1 I6 x1 1 0 x x1 1 1 I7 x
Obviously, these results will not be satisfactory when trying to obtain a full working array of SONARs. A new programmable device, called the PEEL22CV10 has been donated to the project. A Dataman-48 UXP will be used to program this device with the exact I/O specifications required by the SONAR PCB. A logic diagram has been completed depicting the fuse connections. The next phase is to convert the diagrams to logic equations in the format required for assembly and compilation before finally downloading them into the chip.
3.5.1.5 Transducer CharacterizationCurrently, only the lateral limits of a transducer’s range have been tested. The lateral limit from the transducer was tested at points approximately 35 inches apart ranging from the transducer to the upper limit of 34 feet away (due to room size restrictions). A transducer and SONAR module were connected to the basic-x chip, and the single SONAR test program was utilized. The readings of the SONAR program were noted when nothing was in its path except the far wall. At each spacing interval between the far wall and the transducer, a test subject moved from the side towards the center of the room until the readings of the SONAR program detected the subject. The lateral distance from the subject to the transducer was then measured. This was repeated for eleven different points. The lateral limits of a transducer as an object gets farther away can be seen in Figure 3-9. A general diagram of the robot’s predicted area of detection and possible blind spots are given in Appendix 4.5.6: Robot Area of Detection.
27
Figure 3-9: Transducer range
3.6 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.6.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.6.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-4.
28
Table 3-4: Task description reference chart
Task Number Task Name2.13.1.1 Select speech recognition software2.13.1.2 Select I/O interface for end effector control2.13.1.3 Consider end effector control solutions2.13.1.4 Consider end effector hardware solutions2.13.1.5 Consider purchase of DC/AC inverter2.13.2.1 Design wheel tachometer circuit2.13.2.2 Design software to interact with wheel tachometers2.13.2.3 Develop navigation algorithm2.13.2.4 Design end effector controller2.13.3.1 Implement speech recognition2.13.3.2 Extend existing GUI software2.13.3.3 Implement wheel tachometer circuit2.13.3.4 Implement software to interact with wheel tachometers2.13.3.5 Install wheel tachometers2.13.3.6 Repair SONAR array2.13.3.7 Implement new end effector2.13.4.1 Characterize SONAR array2.13.4.2 Test newly developed software2.13.4.3 Automate software testing2.13.4.4 Test new end effector2.13.5.1 Document wheel tachometer circuit2.13.5.2 Document newly developed software2.13.5.3 Document end effector controller design2.13.6.1 Present robot to campus visitors2.13.6.2 Develop scripts and macros for demonstrations2.13.7 Project reporting
3.6.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.
3.6.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.
There are quite a few differences between the expected hours and the actual hours to date. Most of the differences, of course, exist because the semester has not yet come to completion;
31
ripoff1, 04/01/05,
Updated –GR Need Hours from Justin
however, it is obvious that there was a large overestimation in the amount of work some tasks would require; for instance, a good baseline for the sensor controller code was located on the controller’s web site, which greatly reduced the amount of time spent learning how to interface with the controller and an incalculable amount of time that would have been spent debugging it and interfacing it with the sensor array.
3.6.1.2 Financial requirementsThis section documents the estimated and to-date financial requirements for this project.
3.6.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-9 : Estimated financial requirements
Parts and Materials W/O labor With Labor DC/AC Inverter $ 100.00 $ 100.00 LS7184 Phase detector Donated Donated AD8170AN Multiplexer Donated Donated LM2907N-8 F-V converter Donated Donated Miscellaneous parts for assembly of final circuit $ 10.00 $ 10.00 Project Poster (including printing) $ 35.00 $ 35.00
Subtotal $ 145.00 $ 145.00
Labor @ $10.50 per hour Kevin Cantu $ 997.50Philip Derr $ 955.50 Jawad Haider $ 714.00 David Hawley $ 787.50 Zachary Kotlarek $ 882.00 Michael Larson $ 955.50 Jeff Parent $ 850.50 Justin Ramussen $ 840.00 Gavin Ripley $ 882.00 Peter Rufino $ 651.00 Jason Sytsma $ 1,018.50
Subtotal $ 9,534.00 Total $ 145.00 $ 9,679.00
32
ripoff1, 03/30/05,
Updated -GR
3.6.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-10 : Actual financial requirements
Parts and Materials W/O labor With Labor DC/AC Inverter $ 71.99 $ 71.99 LS7184 Phase detector Donated Donated AD8170AN Multiplexer Donated Donated LM2907N-8 F-V converter Donated Donated Miscellaneous parts for assembly of final circuit $ 0.00 $ 0.00 Project Poster (including printing) $ 19.30 $ 19.30
Subtotal $ 91.29 $ 91.29
Labor @ $10.50 per hour Kevin Cantu $ 567.00Philip Derr $ 351.75 Jawad Haider $ 336.00 David Hawley $ 441.00 Zachary Kotlarek $ 493.50 Michael Larson $ 367.50 Jeff Parent $ 420.00 Justin Ramussen $ 441.00 Gavin Ripley $ 514.50 Peter Rufino $ 451.50 Jason Sytsma $ 661.50
Subtotal $ 5,045.25 Total $ 91.29 $ 5,136.54
3.6.2 SchedulesThis section provides a view of this semester’s schedule and compares the estimates with their actual values.
3.6.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 and portions of the task list are not completed, but on schedule. Some tasks, however, are so far behind schedule that they have been delayed until next year, such as the implementation of the end effector.
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.
33
ripoff1, 04/01/05,
This Gantt needs redone. Perhaps an add-in before Lamont grades it because I don’t have the patience to do it now.
ripoff1, 04/01/05,
Need details on money spent for Inverter & Misc. Parts Change totals for Justin Also update subtotal (for parts and labor) and total
Figure 3-10 : Actual project schedule 1
34
The 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-11 : Deliverable schedule
35
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 Software development: Most of the software was developed on schedule according to
specification. However, much of the software is dependent on other systems, such as the SONAR array and wheel tachometers. The software can be modified to integrate with these systems once they are complete.
Wheel tachometer circuit design: A sensible design for this circuit was created very quickly and was soon ready for implementation and testing.
4.1.2 What did not go well Repairing the SONAR array: As one of the primary goals of the project, it is
disappointing that the SONAR array is not working correctly. Even though significant advances have been made, the delay here is delaying the entire project.
Wheel tachometer circuit implementation: Since the design went so well, it was also disappointing that the circuit has still not been built. This task delay has delayed the entire project in a way similar to the SONAR array.
Obtaining parts: A shipment of some essential parts for the wheel tachometer circuit was shipped back to the supplier because it was delivered to the wrong professor on campus.
National Instruments parts: A lot of resources were spent trying to determine how to integrate National Instruments’ products with the robot. This time was not well spent because the integration was ultimately determined impractical for the robot’s system.
Computer upgrade donation: A proposal for a computer system upgrade was sent to Lockheed Martin early in the semester. The contact there left on a business and no donation has yet been received.
Delayed ME support: Since support was limited this semester, our team did not receive mechanical engineering support with enough time left to complete the required tasks.
Project poster: After placing first last semester, it was disappointing that the poster did not do very well this semester.
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:
One of the larges problems facing the sensor team at this moment is the programming of the new multiplexer. Because none of the team members knew how to program the new chip, it has been a rather large project just to get that working, and as mentioned before, finding help with that has been rather difficult if not downright impossible. Because it is
36
ripoff1, 04/01/05,
Updated -GR
ripoff1, 04/01/05,
Updated -GR
ripoff1, 04/01/05,
Updated -GR
anticipated that the multiplexer will be working in the next few weeks, a tremendous amount of technical knowledge will be gained before then.
In order to achieve the goals of this project for this semester, a microcontroller required reprogramming; however, even before programming could take place, an exhaustive diagram of all the circuitry currently in place on the robot and an analysis to determine its function were necessary. This process resulted in an enormous gain in technical knowledge which has been stored for use by future semesters. The microcontroller has been programmed, which itself required quite a bit of study, and that code has been stored for use by future teams should it become necessary.
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 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 Obtaining circuit parts: As soon as the wheel tachometer design was ready, an urgent
request for the parts should have been made. If the wheel tachometer circuit had been available earlier in the semester, much more progress would have been made toward its implementation.
Sensors: Though it was expected that the sensors would create problems for this semester, it was unanticipated that they would still be nonfunctional at this point. Though it is fully expected that they will be fully operational in time for the IRP, it would have been nice if the error had been found sooner.
Time estimation: It was discovered during the course of the semester that there was a substantial discrepancy between the anticipated and actual time spent working on this project. Part of this is because there was more individual work to be done and less time was spent in group meetings discussing it, as everyone had their own particular goal. The other part of this is simple overestimation. Should the scheduling be done again, much more time in the planning meetings would be allocated to coming up with accurate estimations.
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.
37
ripoff1, 04/01/05,
Needs Update
ripoff1, 04/01/05,
Somewhat updated -GR
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.
38
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 Ordered parts do not arrive on timeWhile extra time was planned for parts to arrive, issues were still experienced when ordering parts. Further, even though these parts were ordered early as per the plan for managing risk, some of the parts still did not arrive on time to be of much use prior to the writing of this report. Once these parts have been implemented, this section will be updated to reflect the overall implications of this encountered risk.
4.2.2.2 Software testing shows bugs in codeAfter testing started on the multithreaded communication system for the GUI, a bug was found that caused random messages to be dropped. This bug was managed by simplifying parts of the design to remove the threading issues. This successfully managed the error and the software is currently working as intended.
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 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.
39
jras, 04/01/05,
UPDATE
4.2.3 Unanticipated risks encountered and attempts to manage themVery few if any unanticipated risks were encountered during this semester’s work, and those that were encountered were not significant enough to even warrant mention. It should be noted that though we expected that the parts we ordered wouldn’t arrive on time, and though extra time was allotted for their delivery, we could not foresee that they would arrive, be delivered to the wrong person, and that that person would return them to the company. This effectively doubled the time it took to order that part, and has delayed all portions of the project related to that part.
4.2.4 Resultant changes in risk management because of unanticipated risksThe risk we encountered which was unanticipated is not the type of risk that causes a change in the risk management guidelines – there is simply no way to account for it short of allotting even more time for delivery. In order to mitigate this risk even further, an attempt will be made to discover the parts necessary for implementation in the fall and to order them before the end of the school year. This should allow plenty of time for the parts to arrive prior to the next semester’s work.
4.3 Project Team InformationThe following section lists pertinent information regarding the client, faculty advisor, and student members of Project OSCAR.
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: [email protected] 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: [email protected] 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 ----------------------------------------
---------------------------------------- Name: LARSON MICHAEL JEROME Phone: 515-572-6083 Email: [email protected] Department: ELECTRICAL ENGINEERING Univ Address: 9106 BUCHANAN HALL City/State: AMES IA 50013 Home City/State: SOLON IA Classification: SENIOR ----------------------------------------
---------------------------------------- Name: PARENT JEFFREY DAVID Phone: 515-572-3066 Email: [email protected] Department: COMPUTER ENGINEERING Univ Address: 2432 WILSON OWENS City/State: AMES IA 50013 Home City/State: BAILEYS HARBOR WI Classification: SENIOR ----------------------------------------
---------------------------------------- Name: RASMUSSEN JUSTIN MICHAEL Phone: 515-598-9394 Email: [email protected] Department: COMPUTER ENGINEERING Univ Address: 200 STANTON APT 503 City/State: AMES IA 50014-6806 Home City/State: WEST DES MOINES IA Classification: SENIOR ----------------------------------------
---------------------------------------- Name: RIPLEY GAVIN D Phone: 309-678-3609 Email: [email protected] Department: COMPUTER ENGINEERING Univ Address: 205 S 5TH ST #814 City/State: AMES IA 50010 Home City/State: WASHINGTON IL Classification: SENIOR ----------------------------------------
---------------------------------------- Name: RUFINO PETER OVU Phone: 515-451-3740 Email: [email protected] Department: ELECTRICAL ENGINEERING Univ Address: 4912 MORTENSEN RD #813B City/State: AMES IA 50014 Home City/State: CEDAR RAPIDS IA Classification: SENIOR ----------------------------------------
---------------------------------------- Name: SYTSMA JASON RICHARD Phone: 515-491-6707 Email: [email protected] Department: ELECTRICAL ENGINEERING Univ Address: 6944 123 LN City/State: INDIANOLA IA 50125 Home City/State: INDIANOLA IA Classification: SENIOR ----------------------------------------
---------------------------------------- Name: TWEED LYNN JOSEPH Phone: 515-296-2863 Email: [email protected] Department: MECHANICAL ENGINEERING Univ Address: 1290 WEST VIEW PLACE City/State: BOONE IA 50036 Home City/State: GARNER IA Classification: SENIOR ----------------------------------------
---------------------------------------- Name: WILLIS DAVID M Email: [email protected] Department: MECHANICAL ENGINEERING Home City/State: WATERLOO 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.
4.5 AppendicesThis section contains relevant diagrams and tables explaining portions of Project OSCAR’s functionality.
4.5.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-12 : 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
Figure 4-13: Power interface panel 2
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-14 : Power interface panel 3
Object Function1 Power inverter fuse Safety fuse for power inverter (30 A)
B
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.5.2 of the Fall 2004 Status Report document.)
C
4.5.2 Specifications for potential end effector control solutionsThe following information was taken from documentation describing previous motor control solutions implemented into the end product. While these solutions are not currently in use, they could prove useful in developing a controller for the end effector assembly. The technologies discussed will be considered.
The old controller design required a discrete H-bridge controller rather than an integrated H-bridge controller such as the LT1158 Integrated Circuit. To build a high current H-bridge driver, four separate general-purpose high current MOSFET drivers were chosen for the application (Texas Instruments TDS2811). Each driver has a 2 A output drive capability.The MOSFET drivers require at least 8 to 9 volt trigger signal at the input terminals. The previous design used the LM629 IC, with only 2.5V output, is well below the minimum requirement of the new circuit. A HEX CMOS lever shifter was chosen to increase the voltage level due to ease of implementation and greater versatility over other options. The overall design is given in Figure 4-15.
The original design of the new circuit used all NMOS transistors, causing the top two MOSFETS to dissipate a large amount of heat. The data in the proceeding section discusses the problems associated with the all NMOS design. After testing and revising the circuit, the circuit illustrated in Figure 4-16 was finally chosen.
This new circuit reduces the number MOSFET drivers from 4 to 2 since each MOSFET IC has two MOSFET drivers. The drivers also have built in input logic and only a HEX inverter IC need be added, and the level shifter has up to 6 level shifting inputs and outputs. The H-bridge was changed so that PMOS transistors drive the voltage high and NMOS transistors drive the voltage low. Only one NMOS/PMOS pair is on at one time. When the diagonal pair is switched to the opposite diagonal pair, the direction of the motor is changed. This allows for very efficient and fast direction control.
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
H
These batteries are designed for starting and deep cycling applications and for use in vehicles with large accessory loads. Recommended Charging Information: Alternator:
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.
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.
I
4.5.4 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-19 : RoboteQ serial pin locations Figure 4-20 : RoboteQ serial connection wiring diagram
Figure 4-21 : RoboteQ serial signal-to-pin assignments
J
4.5.5 US Digital S1-256-B optical encoder specificationsPhysical and mechanical diagrams of the US Digital S1 series optical encoder are seen in Figure4-22 and Figure 4-23 below.
Figure 4-22 : US Digital S1 optical encoder
Figure 4-23 : Mechanical drawing of US Digital S1 optical encoder
K
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.
Specification ValueHole Diameter 0.375 in. +0.005 - 0Panel Thickness 0.125 in. max.Panel Nut Max. Torque 20 in.-lbs.
Table 4-13 : Optical encoder electrical pin-out
Pin Description1 Ground2 Index3 A channel4 +5VDC power5 B channel
L
4.5.6 Robot Area of DetectionBased on the lateral SONAR characterization testing, an overall model can be developed to estimate what areas the SONARs detect and where there may be blind spots. Figure shows the predicted area of detection for the robot. The diameter of the circle of detection spans 68 feet.
Figure 4-24: Area of detection using all eight SONARs
M
4.5.7 D-Link DWL-122 SpecificationsThe following specifications of the wireless ethernet units were taken from the product manufacturer’s website.
Table 4-14 : 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)
N
4.5.8 SONAR array schematicsThe following sections provide schematics for the 6500-series ranging module and the BX-24 microcontroller.
