710 likes | 724 Views
Faculty Advisor Dr. Ralph Patterson. April 25, 2001. Project Cybot Ongo01. Project leaders Josh Bertram Ben Martin. Client: Department of Electrical and Computer Engineering. Introduction. Cybot. OSCAR. Problem Statement. Focused on OSCAR Expand OSCAR’s capabilities
E N D
Faculty Advisor Dr. Ralph Patterson April 25, 2001 Project CybotOngo01 Project leaders Josh Bertram Ben Martin Client: Department of Electrical and Computer Engineering
Introduction Cybot OSCAR
Problem Statement Focused on OSCAR • Expand OSCAR’s capabilities • Need software • Need better control of motion • Need to know power usage • Need to sense environment • Need to interact with environment
Project Teams • Software • Control and user interface software • Motion Control • Upgrade/maintain motion control hardware • Power • Determine power usage • Sensor • Create sonar array • End-Effector • Create an arm
Software Team Members: • Sean Wiechman (CprE – 2nd) – team leader • Fransiskus Arif Komala (CprE – 2nd) • Curtis Balmer (CprE – 2nd) • Adnan Khan (CprE – 2nd) • Caleb Huitt (CprE – 1st) • Muhammad Saad Safiullah (CprE – 1st) • Anthony Bozeman (CprE – 1st)
Problem Statement • Create simple, powerful software solutions to control OSCAR, working with other subsystems such as Sensors and Motion Control • Last semester, rudimentary motion control drivers and wireless network communication developed. • OSCAR’ s drivers buggy and demonstrations applications interface insufficient • OSCAR needs additional methods of control • Need to be able to communicate with sensors
Design Objectives • Debug and validate driver code • Develop a suitable interface for demonstration application developers • Implement control over the Internet • Implement voice control • Develop software to interact with Sensor sub-team’s software
System allowing accurate control of OSCAR through Internet and voice control The interface to each component will be as simple as possible Able to obtain sensor information The system will be fully documented The motion control hardware on OSCAR is functional The sound card on OSCAR is operational Auxiliary computer able to simultaneously use two network cards Delay over the networks negligible End ProductDescription Assumptionsand Limitations
System Overview VoiceCommand Web Browser Voice Recognition Software Java Server Pages Code OSCAR’s Keyboard Drivers
Technical Approach • Drivers will be debugged and tested • Easily understood interface will be created for application developers • Voice control will be implemented using the Java Development Kit for IBM’s ViaVoice
Internet control will be attained using HTML forms and Java Server Pages (JSP) Communication with sensors will take place over a serial port connection using protocol defined by Sensors sub-team Documentation will be completed and backed up to several locations Technical Approach
Driver code is debugged and tested Intuitive interface for demonstration applications created Voice control software is almost complete Internet control software created Sensor software created Create software to interact with the end-effector subsystem Develop demonstration applications to further utilize capabilities Document future work Create additional diagnostic utilities for use by other sub-teams Evaluation of Project Success Additional Work
Very important to test hardware early Learned about: - Java - Voice Technologies -Web Technologies -Motion Control interface Completed software to facilitate easy control of OSCAR in various ways Working out last problems with hardware on OSCAR’s computer Work is documented and will be easily extended by future teams Summary Lessons Learned
Motion Control Team Members: • Josh Bertram (CprE – 2nd ) – team leader • Jo-Yi Foo (EE – 2nd ) • Sath Sivasothy (EE – 1st) • Rius Tanadi (EE – 1st)
Robot movement Hardware broken/unstable Incomplete documentation Debug and maintain robots Document system fully Design Objectives Problem Statement
Working robot Documentation Conceptual Technical End Product Description
Questioned original assumptions Was old software/hardware validated? Limitations Robot stopped working Incomplete documentation Robots often used for presentations Assumptions and Limitations
Computer Motion Control Subsystem Motor(s) Technical Approach Subsystem “Black Box”
Subsystem Components Motion Control Subsystem CPU CPU Interface Motion Controller Motor Driver Motion Detector Motor
Evaluation of Project Success Design Objective Analysis • Robots • Debug OSCAR – MET • Maintain Cybot – PARTIALLY MET • Documentation • Create conceptual documentation – MET • Upgrade technical documentation – MET • Create test descriptions – MET • Budget
Aid end-effector team Develop circuit enclosure Tutorial Additional Work
Lessons Learned • Debug • Isolation of variables • Component validation • Documentation • Audience analysis • Non-technical writing
Summary • OSCAR works • Better foundation • Better documentation • Better testing procedures
Members: Kiet Nguyen (EE – 2nd) co-leader Nick Sternowski (EE – 1st ) co-leader Nathan Nguyen (EE – 2nd) Power Team
To provide effective power system support Provide a 5 Volt, 2 Ampere source to sensor team Determine power budget Install and test new battery monitor Re-program existing battery monitor Collect and analyze power consumption from sub teams Design, build, test power supply for sensor array Determine alternate way to charge batteries Design Objectives Problem Statement
OSCAR will operate with charged batteries Sensor array can handle very short 4 A pulse Power supply will not overheat Batteries can be run down to 25% Battery monitors are accurate to +/-5% Ampere-hour figures are peak conditions Assumptions & Limitations
Technical Approach • Use a switching voltage regulator • Create circuit for voltage regulator • Correctly program battery monitors • Fully test all systems before installation
End Product Description • Stable, reliable power supply for sensor array • Accurate battery monitors • Documentation explaining design techniques • Power consumption figures
Evaluation of Project Success • Install and program two accurate battery monitors – MET • Simple method of charging batteries simultaneously - MET • Build 5 Volt, 2 Ampere source for sensor subteam – MET • Documented power consumption statistics - MET
Additional Work • Add protection for each sub system and major component • Removal of DC/AC inverter • Supply power to end effector team
Communication with other groups Documentation for future teams Selection of voltage regulators Documentation provided by manufacturers Lessons Learned
Sensor Team Members: • Ben Martin (CprE – 2nd) – team leader • Jill Bigley (CprE – 2nd) • Adam Kasper (CprE – 1st) • Chris Hutchinson (CprE – 1st) • Saw-Meng Soo (CprE – 1st) • Naveen Byreddy (CprE - volunteer)
Provide sensing capabilities Finish sonar system Design software for sonar system Integrate hardware components Documentation Modular design Future expandability Software interface Accurate and reliable Design Objectives Problem Statement
Eight individual distance measuring sensors Simple computer interface Capable of logging data Modular design Appropriate power can be provided Accurate from 40 cm - 10 m One sonar fires at a time Limited memory available for data logging End ProductDescription Assumptionsand Limitations
Technical Approach:Hardware Sensor Driver Board Micro-controller Computer Interface
Technical Approach:Hardware to micro- controller
Technical Approach:Hardware Computer Interface Ribbon cable to driver boards Micro- controller Multiplexer