Post on 13-Jan-2016
Project Cybot - Ongo01
December 12, 2001
Project Leaders:• Sath Sivasothy• Caleb Huitt
Faculty Advisor:• Dr. Ralph Patterson
Client:• Department of Electircal and Computer Engineering
Acknowledgements:• Dr. Lawrence Genalo
Presentation Outline• Overview • Sensors• Power• End-Effector• Motion Control• Software• Interactive Learning• Summary
Introduction
OSCAR (Concept) OSCAR (Current)
Team Cybot History- Once a club
- Robots:Zorba - No longer exists
Cybot - Department Ambassador- Many demonstrations- Now failing
OSCAR - Newest robot- Being designed and built
Organization• Six subteams
• Sensors • Power• End-Effector• Motion Control• Software• Interactive Learning (New Addition)
• Weekly subteam meetings
• Weekly team leader meetings
• E-mail mailing lists
Subteam Interaction
Previous AccomplishmentsCybot:
• Complete motion control
• Moving arm
• Speech and voice recognition• Many and complex demonstrations
OSCAR:• Complete design
• Motion control
• Sensors installed
• Gripper fabricated
Beginning of the SemesterCybot:
• Motion control inoperable• Arm stopped working over summer• Speech still works• Very few demonstrations work
OSCAR:• Motion control nearly complete• Few demonstrations• Sensors usually working• Arm design nearly complete• Solid power system• Few people know about robot
End GoalsCybot:
• Restore to previous functionality
OSCAR:• Robot can accomplish tasks autonomously
• Speech control and interaction
• Internet interface for remote learning
• Ability to demonstrate with a few minutes notice
• Take over Cybot’s role as ambassador
• Become famous (at least on campus)
Semester GoalsConcentrate on OSCAR:
• Motion control stabalized• Sonar sensors working• New sensors installed• Easier robot control:
- Voice
- Arrow keys• New computer power supply• Finish arm design• Manufacture more of arm• Investigate ways to get robots “heard about”• Give demonstrations of robots
Risks and Concerns• Problems with previous work
• Hardware breakdown
• Time available
• Personnel problems
• Technical knowledge
• Demonstrations
Risk Management• Test early
• Deal with it as the problems arise
• Schedule properly
• Stay flexible in assignments
• Good documentation
• Keep Cybot as functional as possible
Questions
Sensors Team
Sensors TeamTeam Members:
• Chris Hutchinson (CprE, 2nd) - team leader
• Adam Kasper (CprE, 2nd)
• Saw Meng-Soo (CprE, 2nd)
• Waqar Habib (EE, 1st)
Problem Statement• Provide sensing capabilities
• Finish sonar system
• Add compass and temperature sensors
• Determine accuracy and limits
• Finalize software interface
Design Objectives• Modular design
• Future expandability
• Low power consumption
• Provide accurate data
Assumptions and LimitationsAssumptions:
• Only one sensing function at a time
• Only one active transducer at a time
Limitations:• Sonar effective from 1.5 to 35 feet
• EM interference affects compass
• Limited microcontroller I/O pins
• Limited power and space
Risks and Concerns• Part damage
• Electromagnetic interference
• Inconsistent data
End Product Description• Distance sensing within +/- 3%
• Temperature sensing within +/- 2° F
• Data filtering
• Reliable software interface
Technical ApproachCompletion of sonar system:
• Multiplex with programmable logic
• Permanently mount all components
• Tweek for accuracy
• Determine limits
TransducerBasicX-24
Microcontroller
Technical ApproachAddition of new sensors:
• Thermistor for temperature sensing
• Dinsmore 1655 Analog Compass
• Tweek for accuracy (ongoing)
Technical ApproachSoftware Interface:
• Serial communication
• Modular / scaleable design
• Simple implementation
• Interface protocol -
1 byte 1 byte 1 byte
ATN Command Operand(s)
Completed System
Problems Encountered• Damaged programmable logic chip
• Memory issues
• Sonar noise
• Transducer dissipation
• Inaccurate compass
Evaluation of Success• Software interface implemented
• Integration of new sensors
• Accurate and reliable reporting of data
• Met financial and time budgets
Future Work• Data accuracy
• Efficiently utilize sensors
• Additional sensors:
- Video imaging
- Tactile / Pressure
- Infrared
Lessons Learned• Experience with the BX-24 microcontroller
• Implementation of analog and digital sensors
• Demonstrations with large groups
• Things break – roll with the punches
Summary• Sensor system is fully functional
• OSCAR has the power to interact
• Ready for further sensing capability
Questions
Demonstrations• Sonar sensors
• Compass sensor
• Thermistor
Power Team
Power TeamTeam Members:
• Nicholas Sternowski (EE, 2nd) - team leader
• Kris Kunze (EE, 1st)
Design Objectives
• Install new batteries
• Replace DC/AC inverter
• Build/Test/Install DC/DC converter
Assumptions and LimitationsAssumptions:
• Batteries in good working condition
Limitations:• Batteries can only be run down to 50%
• Initial power system design not available
• Limited budget
•No experience with PCB fab
Risks and Concerns• Short circuit
• Power system with charger
Technical Approach• Cheaper is better!
• Utilize readily available batteries
• Parallel DC/DC converters
Technical Approach
Technical Approach
Technical Approach
Problems Encountered• PCB fabrication
• Part order delays
Evaluation of Success• DC/DC converter design determined
• PCB fabrication
• Parts ordered
• Batteries installed & functioning
Future Work• Completing of DC/DC converter
• Provide power to sensor, end effector teams
• System protection
Lessons Learned• Power supply operation
• Slow drain on batteries cause failure
• PCB fabrication
• Minimum order requirements are a killer
Summary• Didn’t meet all goals
• Work needed identified
Questions
End-Effector Team
End-Effector TeamTeam Members:• Jet Ming Woo (EE – 2nd ) – team leader
• Alex Mohning (ME – ME 466 )
• Alex Rodrigues (ME – ME 466)
• Chris Trampel (EE – 1st)
• Yan Chak Cheung (EE – 1st)
• Jim Schuster (Cpre – 1st)
Design Objectives• Full range of movement• Move at reasonable speed• Lift 2 lb objects
− 1 lb at full arm extension• Lift 3” diameter objects• Controlled by OSCAR’s central computer • Modular approach
Assumptions and LimitationsAssumptions:
• Sufficient funding for the fabrication of arm All motors will operate at 12 volts
Limitations:• Arm pivoted on top of OSCAR
• Use JAVA to write the program
• 12V available for gripper
Risks and Concerns• Cost of development
• Availability of parts
• Power Consumption of motors
Risk Management• Search for cheaper parts
• Buy parts over several semesters
• Look for cheaper designs
• Buy widely used motors at the start of the semester after designing the arm
• Search for parts with low power consumption
Technical Approach• Assembly and testing of the gripperAssembly and testing of the gripper
• RResearch on existing control circuitsesearch on existing control circuits
• Develop software and electronic control Develop software and electronic control circuitscircuits
• Develop detailed drawings and Develop detailed drawings and schematics for the wristschematics for the wrist
Wrist Control Circuit
PC
MotionControllerLM 629
Half-BridgeMOSFET Driver
LT 1158Half-Bridge
DCWristMotor
MotionControllerLM 629
Half-BridgeMOSFET Driver
LT 1158Half-Bridge
PWM
PWM
Quadrature Incremental Feedback
Gripper Control Circuit
PCDC
GripperMotor
4 Phase StepperMotor DriveUCN 5804B
Dual Full BridgeMotor DriverUDN2998W
Inductance to Resistance Drive Card
Gripper Design• Stepper actuatorStepper actuator
– InexpensiveInexpensive– CompactCompact– Linear drive Linear drive without transmissionwithout transmission
• Linkages easy to Linkages easy to manufacturemanufacture• Interchangeable Interchangeable fingersfingers
Overall Design
• Arm will pivot on Arm will pivot on top-center of OSCARtop-center of OSCAR
• Aluminum linksAluminum links
• Joints use modular Joints use modular worm gear assemblyworm gear assembly
• Driven by Pittman Driven by Pittman DC motorsDC motors
Wrist Design
• 360º rotation360º rotation
• 270º bend at wrist 270º bend at wrist jointjoint
• Separate motors for Separate motors for bend and rotationbend and rotation
• Utilizes similar Utilizes similar components as rest of components as rest of armarm
Worm Drive for Bend
• Pittman DC motorPittman DC motor
– Reduced speedReduced speed
– Readily availableReadily available
– ReliableReliable
• Worm assemblyWorm assembly
– Dramatic torque gainsDramatic torque gains
– No back drive – save No back drive – save powerpower
Gear Drive for Twist
• Spur gear driveSpur gear drive
– Reduced speedReduced speed
– Torque gainsTorque gains
– Linear transmissionLinear transmission
Problems Encountered• Lost of financial sources
• Team members not familiar with JAVA
Evaluation of Success• Motor installed in gripper and functional
• Control circuit for gripper is ready
• Gripper’s software is almost done
• Wrist design completed
• Wrist control circuit schematic is drawn
Future Work• Draw layout of circuit using PCB program
• Build the control circuit boards for all motors
• Modify wrist design
• Machine and assemble the arm
• Software for the arm
Lessons Learned• Program and test I/O card on OSCAR
• JAVA language
• H-bridge
Summary• Gripper motor installed and functioning Gripper motor installed and functioning
• Wrist design is detailed and completedWrist design is detailed and completed
• Future work planned for the completion Future work planned for the completion of armof arm
Questions
4.00”
3.75”
8.5”
Demonstrations• Gripper
Motion Control Team
Motion Control Team
Members:
• Rius Tanadi (EE – 2nd ) – team leader
• Brooks Graner (CprE – 1st )
• Boon-Siang Cheah (CprE – 1st )
Problem Statement
• Robot movement
• Hardware broken/unstable
• Further research on new circuit implementation
Design Objectives
• Debug and maintain motion control
hardware
• Reliable software interface
End Product Description
• OSCAR’s motion will be fully operational
• Improve motion control design
Assumptions and Limitations• Original assumptions
– Old software/hardware validated
• Limitations
– Robot breaks down
– Robot used for presentations
Risks and Concerns• Short circuit
• Over-heating components
• Loss of current members
System OverviewSubsystem block diagram
Computer
Motion Control Subsystem
Motor(s)
Technical Approach
CPU
Motor
CPU Interface
Motion Controller
Motor Driver
Motion Detector
Motion control subsystem
Technical Approach
• Motion control circuitry will be
debugged and tested
- Individual/component testing
- Sub-system testing
• Reliable software interface will be
created
- Create GUI
Evaluation of Success• Robots
- Debug OSCAR (partially met)
- GUI interface (met)
• Budget
Additional Work• Test the remaining components
• Trace motion control design
• Aid end-effector team
• Research on circuit implementations
Lessons Learned
• Debug
- Isolation of variables
- Component validation
• Interact with people
Summary• OSCAR debug is still in progress
• Clean up all the design flaws
• Research for a better design
Questions
Software Team
Software TeamTeam Members:
• Caleb Huitt (CprE, 2nd) - team leader
• Muhammad Saad Safiullah (CprE, 2nd)
• Anthony Bozeman (CprE, 2nd)
• Sastra Winarta (CprE, 1st)
• John Wyman (CprE, volunteer)
Problem Statement• Provide easy SW motion control
• Provide voice control
• Use sensor information
• Develop demonstrations
Design Objectives• Modular design
• Easily Expandable
• Separates drivers from logic
• Allows component testing
• Accessable interfaces
• Consistent techniques
Assumptions and LimitationsAssumptions:
• Operators have basic computer skills
• Subteam members have basic programming skills
• Software developed for properly functioning hardware
Limitations:• Current documentation is incomplete
• Much time needed to learn subsystem
• Hardware breakdowns limit software testing
Risks and Concerns• Hardware insufficient/inconsistent
• Members without needed experience
• Interoperability problems
Risk Management• Investigate hardware early
• Detail necessary & optional purchases
• Provide explanatory papers
• Provide research tasks
• Iterative design approach
End Product Description• Verify motion control driver code
• Allow arrow keys to control motion
• Implement voice control
• Expand sensor software
• Integrate sensor software
• Develop new demonstrations
Technical Approach• Three-tier software design
• Modular
• Extensible
• Programming languages based on needs• C for drivers
• Java for higher levels
• Use previously developed solutions
Technical ApproachSoftware Three-Tier Approach:
Second Tier (Application Logic)
Third Tier (User Interface Logic)
First Tier (Direct Control Software)
Technical Approach• Motion control drivers tested/debugged
• Use JDK for IBM’s ViaVoice
• Sensors:• Communication over serial port• Protocol defined by Sensors subteam
• Arm driver design based on motion control’s
Problems Encountered• Motion Control subteam debugging
• Sound card problems
• Previous sensors software unusable
• Java programming problems
• Volunteer stopped after 1/2 semester
Evaluation of Success• Motion control software debugged
• Arrow key motion software working
• Sensors software interface rewritten
• Voice control software working
• Goals not completely met
• Many problems overcome
Future Work• Software for end-effector
• Speech synthesis
• Integrate sensors data
• Develop more demonstrations
• Work on autonomous navigation
Lessons Learned• Motion control implementation
• Java programming language
• IBM’s ViaVoice technology
• Serial port communication
• Software keystroke detection
Summary• Didn’t meet all goals
• Overcame a variety of problems
• Have much work to do in the future
Questions
Demonstrations• Arrow key control of motion
• Voice control proof-of-concept
Interactive Learning Team
Interactive Learning TeamTeam Members:
• Kivanc Kahya (CprE, 1st) - team leader
• John Davidson (CprE, 1st)
Design Objectives• Initiate educational system using OSCAR
• Develop robotics education curriculum
• Initiate Internet-based remote control system
• Add additional functionality (if required)
• Consider using LEGO® Mindstorms robots
Assumptions and LimitationsAssumptions:
• OSCAR will soon be fully functional
• Required technologies are available
• Client will be found
Limitations:• Client’s current technology infrastructure
• Number of students using the system simultaneously
• Funding
Risks and Concerns• Integration of additional hardware/software
• Qualified robotics teacher for client
• Too many interested clients
• Client may lack necessary technology
• Complicated programming interface
• Lack of experience in design team
Risk Management• Assistance from Toying with Technology
• Well defined software design process
• Peer reviews
• Detailed software test procedures
Technical Approach• Technology
• Internet-based remote control system
• Inter-communication between multiple robots
• Educational Materials
• Structured exercises
• Robotics workshops
• Sponsorship of robotics competitions
Problems Encountered• Excessive time spent on initial documentation
• Delayed contact responses
Evaluation of Success• Team poster completed
• Gathered significant information
• Objectives accomplished
Future Work• Conceptual design
• Software system requirements
• Develop robotics curriculum
• Search for funding
• Develop demonstrations
Lessons Learned• Initiating a project without clear understanding of
the problem is difficult
Summary• Interactive learning project initiated
• Compiled information sufficient to initiate development
• Met all semester goals
Questions
Financial Budget
Effort Budget
1100
1150
1200
1250
1300
1350
1400
Hours
Estimated Budget Actual Budget
Overall Effort Budget
Semester Accomplishments• Thermal/compass/distance sensors
• Motion control GUI
• Wrist design
• DC/DC converter design
• Strategic planning
• Voice Control
• Successful Demonstrations
Future Goals• Implement DC/DC converter
• Manufacture remainder of arm
• Achieve compass/sensor accuracy
• Implement sensors software
• Implement end-effector software
• Continue and improve demonstrations
Overall Summary• Completed documentation
• Effective team communication
• Overcame unexpected problems
• Stayed well under budget
• Semester was a success
Final Questions