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