1. Faculty Advisor –Dr. Ralph Patterson Project Cybot Ongo01 Project leaders – Josh Bertram – Ben Martin Client:Department of Electrical and Computer Engineering April 25, 2001

2. Introduction Cybot OSCAR

3. Problem Statement Focused on OSCAR Expand OSCAR’s capabilitiesExpand OSCAR’s capabilities –Need software –Need better control of motion –Need to know power usage –Need to sense environment –Need to interact with environment

4. Project Teams SoftwareSoftware –Control and user interface software Motion ControlMotion Control –Upgrade/maintain motion control hardware PowerPower –Determine power usage SensorSensor –Create sonar array End-EffectorEnd-Effector –Create an arm

5. Project Budgets

6. Software Team

7. Members: Sean Wiechman (CprE – 2 nd ) – team leaderSean Wiechman (CprE – 2 nd ) – team leader Fransiskus Arif Komala (CprE – 2 nd )Fransiskus Arif Komala (CprE – 2 nd ) Curtis Balmer (CprE – 2 nd )Curtis Balmer (CprE – 2 nd ) Adnan Khan (CprE – 2 nd )Adnan Khan (CprE – 2 nd ) Caleb Huitt (CprE – 1 st )Caleb Huitt (CprE – 1 st ) Muhammad Saad Safiullah (CprE – 1 st )Muhammad Saad Safiullah (CprE – 1 st ) Anthony Bozeman (CprE – 1 st )Anthony Bozeman (CprE – 1 st )

8. Problem Statement Create simple, powerful software solutions to control OSCAR, working with other subsystems such as Sensors and Motion ControlCreate 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.Last semester, rudimentary motion control drivers and wireless network communication developed. OSCAR’ s drivers buggy and demonstrations applications interface insufficientOSCAR’ s drivers buggy and demonstrations applications interface insufficient OSCAR needs additional methods of controlOSCAR needs additional methods of control Need to be able to communicate with sensorsNeed to be able to communicate with sensors

9. Design Objectives Debug and validate driver codeDebug and validate driver code Develop a suitable interface for demonstration application developersDevelop a suitable interface for demonstration application developers Implement control over the InternetImplement control over the Internet Implement voice controlImplement voice control Develop software to interact with Sensor sub-team’s softwareDevelop software to interact with Sensor sub-team’s software

10. End Product Description System allowing accurate control of OSCAR through Internet and voice controlSystem allowing accurate control of OSCAR through Internet and voice control The interface to each component will be as simple as possibleThe interface to each component will be as simple as possible Able to obtain sensor informationAble to obtain sensor information The system will be fully documentedThe 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 Assumptionsand Limitations Assumptions and Limitations

11. System Overview Voice CommandWeb Browser OSCAR’s Keyboard Voice Recognition Software Java Server Pages Code Drivers

12. Drivers will be debugged and tested Drivers will be debugged and tested Easily understood interface will be created for application developers Easily understood interface will be created for application developers Voice control will be implemented using the Java Development Kit for IBM’s ViaVoice Voice control will be implemented using the Java Development Kit for IBM’s ViaVoice Technical Approach

13. Internet control will be attained using HTML forms and Java Server Pages (JSP)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-teamCommunication 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 locationsDocumentation will be completed and backed up to several locations Technical Approach

14. Effort Budget

15. Evaluation of Project Success Driver code is debugged and testedDriver code is debugged and tested Intuitive interface for demonstration applications createdIntuitive interface for demonstration applications created Voice control software is almost completeVoice control software is almost complete Internet control software createdInternet control software created Sensor software createdSensor 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 AdditionalWork

16. Very important to test hardware earlyVery important to test hardware early Learned about: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

17. Motion Control Team

18. Members: Josh Bertram (CprE – 2nd ) – team leaderJosh Bertram (CprE – 2nd ) – team leader Jo-Yi Foo (EE – 2nd )Jo-Yi Foo (EE – 2nd ) Sath Sivasothy (EE – 1st)Sath Sivasothy (EE – 1st) Rius Tanadi (EE – 1st)Rius Tanadi (EE – 1st)

19. Robot movementRobot movement Hardware broken/unstableHardware broken/unstable Incomplete documentationIncomplete documentation Debug and maintain robots Document system fully Design Objectives Problem Statement

20. End Product Description Working robotWorking robot DocumentationDocumentation –Conceptual –Technical

21. Assumptions and Limitations Questioned original assumptionsQuestioned original assumptions –Was old software/hardware validated? LimitationsLimitations –Robot stopped working –Incomplete documentation –Robots often used for presentations

22. Technical Approach Subsystem “Black Box” Computer Motion Control Subsystem Motor(s)

23. Subsystem Components Motion Control Subsystem CPU Motor CPU Interface Motion Controller Motor Driver Motion Detector

24. Evaluation of Project Success Design Objective Analysis RobotsRobots –Debug OSCAR – MET –Maintain Cybot – PARTIALLY MET DocumentationDocumentation –Create conceptual documentation – MET –Upgrade technical documentation – MET –Create test descriptions – MET BudgetBudget

25. Financial Budget

26. Effort Budget

27. Additional Work Aid end-effector team Develop circuit enclosure Tutorial

28. Lessons Learned DebugDebug –Isolation of variables –Component validation DocumentationDocumentation –Audience analysis –Non-technical writing

29. Summary OSCAR worksOSCAR works Better foundationBetter foundation –Better documentation –Better testing procedures

30. Power Team

31. Members: Kiet Nguyen (EE – 2nd) co-leaderKiet Nguyen (EE – 2nd) co-leader Nick Sternowski (EE – 1st ) co-leaderNick Sternowski (EE – 1st ) co-leader Nathan Nguyen (EE – 2nd)Nathan Nguyen (EE – 2nd)

32. Design Objectives To provide effective power system supportTo provide effective power system support Provide a 5 Volt, 2 Ampere source to sensor teamProvide a 5 Volt, 2 Ampere source to sensor team Determine power budgetDetermine 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 Problem Statement

33. Assumptions & Limitations OSCAR will operate with charged batteriesOSCAR will operate with charged batteries Sensor array can handle very short 4 A pulseSensor array can handle very short 4 A pulse Power supply will not overheatPower supply will not overheat Batteries can be run down to 25% Battery monitors are accurate to +/- 5% Ampere-hour figures are peak conditions

34. Technical Approach Use a switching voltage regulatorUse a switching voltage regulator Create circuit for voltage regulatorCreate circuit for voltage regulator Correctly program battery monitorsCorrectly program battery monitors Fully test all systems before installationFully test all systems before installation

35. End Product Description Stable, reliable power supply for sensor arrayStable, reliable power supply for sensor array Accurate battery monitorsAccurate battery monitors Documentation explaining design techniquesDocumentation explaining design techniques Power consumption figuresPower consumption figures

36. Battery Monitor

37. Power Supply for Sensor Array

38. Financial Budget

39. Effort Budget

40. Evaluation of Project Success Install and program two accurate battery monitors – METInstall and program two accurate battery monitors – MET Simple method of charging batteries simultaneously - METSimple method of charging batteries simultaneously - MET Build 5 Volt, 2 Ampere source for sensor subteam – METBuild 5 Volt, 2 Ampere source for sensor subteam – MET Documented power consumption statistics - METDocumented power consumption statistics - MET

41. Additional Work Add protection for each sub system and major componentAdd protection for each sub system and major component Removal of DC/AC inverterRemoval of DC/AC inverter Supply power to end effector teamSupply power to end effector team

42. Lessons Learned Communication with other groupsCommunication with other groups Documentation for future teamsDocumentation for future teams Selection of voltage regulatorsSelection of voltage regulators Documentation provided by manufacturersDocumentation provided by manufacturers

43. Sensor Team

44. Members: Ben Martin (CprE – 2nd) – team leaderBen Martin (CprE – 2nd) – team leader Jill Bigley (CprE – 2nd)Jill Bigley (CprE – 2nd) Adam Kasper (CprE – 1st)Adam Kasper (CprE – 1st) Chris Hutchinson (CprE – 1st)Chris Hutchinson (CprE – 1st) Saw-Meng Soo (CprE – 1st)Saw-Meng Soo (CprE – 1st) Naveen Byreddy (CprE - volunteer)Naveen Byreddy (CprE - volunteer)

45. Design Objectives Provide sensing capabilitiesProvide sensing capabilities Finish sonar systemFinish sonar system –Design software for sonar system –Integrate hardware components –Documentation Modular design Future expandability Software interface Accurate and reliable Problem Statement

46. End Product Description Eight individual distance measuring sensorsEight individual distance measuring sensors Simple computer interfaceSimple computer interface Capable of logging dataCapable of logging data Modular designModular design Appropriate power can be provided Accurate from 40 cm - 10 m One sonar fires at a time Limited memory available for data logging Assumptionsand Assumptions andLimitations

47. Technical Approach: Hardware Sensor Driver Board Micro-controller Computer Interface

48. to micro- controller Technical Approach: Hardware

49. Computer Interface Multiplexer Ribbon cable to driver boards Micro- controller Technical Approach: Hardware

50. Completed system

51. Interface Protocol - 1 byte Commands - Single fire (FireRaw) Single fire (FireRaw) Multiple fire (FireFilter) Multiple fire (FireFilter) Micro-controller Reset Micro-controller Reset Modular Modular ATNCommandOperand(s) Technical Approach: Software

52. Evaluation of project success Sonar software system implementedSonar software system implemented Systems integration successfulSystems integration successful Accurate and reliable ranging systemAccurate and reliable ranging system BudgetsBudgets Implement sonar grid Develop transducer cones Develop sonar analysis software Other sensors: –End-effector –Temperature –Compass Additional Work

53. Financial Budget

54. Effort Budget

55. Gained practical experience with:Gained practical experience with: –Sonar hardware –Firmware –Programmable Logic Devices –PCB design and manufacture OSCAR’s sensor system is fully functional Environmental feedback is available for the first time Summary Lessons Learned

56. End-Effector Team

57. Members: Tim McCormick (CprE – 2nd ) – team leaderTim McCormick (CprE – 2nd ) – team leader Linda Lua (EE – 2nd )Linda Lua (EE – 2nd ) Mike Taylor (ME – 2nd)Mike Taylor (ME – 2nd) Jet Ming Woo (EE – 1st)Jet Ming Woo (EE – 1st) Stephen Shi (CprE – 1st)Stephen Shi (CprE – 1st) Mark Bly (ME – 2nd)Mark Bly (ME – 2nd) John Cao (ME – 2nd)John Cao (ME – 2nd)

58. Problem Statement OSCAR needs an end-effectorOSCAR needs an end-effector Basic physical features of arm identifiedBasic physical features of arm identified Decide on details of implementation and create detailed design of armDecide on details of implementation and create detailed design of arm Build portion of armBuild portion of arm Full range of movement Move at reasonable speed Lift 2 lb objects (1lb at full arm extension) Lift 3” diameter objects Controlled by OSCAR’s central computer Modular approach Design Objectives

59. Technical Approach Limited time and budget Limited time and budget Developed over several semesters Developed over several semesters Limited manufacturing experience Limited manufacturing experience Limited power consumption Limited power consumption Must run on 12 Volts and 1.5 amps Must run on 12 Volts and 1.5 amps Develop a concept for the design of the arm Develop a concept for the design of the arm Analysis of design Analysis of design Specification of components Specification of components Develop detailed drawings and schematics Develop detailed drawings and schematics Develop software and electronic control circuits Develop software and electronic control circuits Assembly and testing Assembly and testing Assumptions and Limitations

60. Gripper Control Design Using Stepping MotorUsing Stepping Motor Control software in JavaControl software in Java Stepper motor controlled by L/R drive cardStepper motor controlled by L/R drive card Higher torqueHigher torque Smaller sizeSmaller size Increased functionalityIncreased functionality Capable of future modificationsCapable of future modifications MicrosteppingMicrostepping Position encodersPosition encoders

61. Gripper Design Stepper actuatorStepper actuator –Inexpensive –Compact –Linear drive without transmission Linkages easy to manufactureLinkages easy to manufacture Interchangeable fingersInterchangeable fingers Base easily attached to armBase easily attached to arm

62. Overall Design Arm will pivot on top- center of OSCARArm will pivot on top- center of OSCAR Aluminum linksAluminum links Driven by Pittman DC motorsDriven by Pittman DC motors Joints use modular worm gear assemblyJoints use modular worm gear assembly CAD drawings of entire arm (excluding wrist) completedCAD drawings of entire arm (excluding wrist) completed

63. Worm Gear Drive Design Pittman DC motorPittman DC motor –Reliable –Reduced speed –Readily available Worm assemblyWorm assembly –Perpendicular transmission –Dramatic torque gains –No back drive – save power Modular designModular design –Easy manufacture –Repeatable spares

64. Evaluation of Project Success Complete detailed design of arm - METComplete detailed design of arm - MET Detailed drawings of completed arm - METDetailed drawings of completed arm - MET Complete plan for future work – PARTIALLY METComplete plan for future work – PARTIALLY MET Develop control circuits for the hand - METDevelop control circuits for the hand - MET Develop control software for the hand – PARTIALLY METDevelop control software for the hand – PARTIALLY MET Manufacture mechanical parts Develop control software Assemble and test arm Incorporate sensors into the control of arm and end-effector Explore possibility of multiple hands Additional Work

65. Financial Budget

66. Effort Budget

67. Lessons Learned Researching as much as possible before deciding on implementationResearching as much as possible before deciding on implementation Don’t reinvent the wheelDon’t reinvent the wheel Working with people from other disciplines is rewardingWorking with people from other disciplines is rewarding Communication is criticalCommunication is critical Hand assembly completed Worm gear assembly detailed Overall design of entire arm completed Future work planned for the completion of arm Summary

68. Project Summary

69. Lessons Learned What went well?What went well? –Communication Weekly meetingsWeekly meetings Three-tier organizationThree-tier organization –Progress Teams met most or all of goalsTeams met most or all of goals What could have been better?What could have been better? –Ramp-up Lost time in first 3-5 weeksLost time in first 3-5 weeks –Report generation process

70. Summary OSCAR closer to autonomousOSCAR closer to autonomous –Core software in place –Can sense environment –Halfway to completed arm Better foundationBetter foundation –Better understand motion control –Know power consumption

71. Questions?