Transcript Project Cybot Ongo-01

April 25, 2001
Project Cybot
Ongo01
Project leaders
– Josh Bertram
– Ben Martin
Client:
Faculty Advisor
– Dr. Ralph Patterson
Department of Electrical and
Computer Engineering
Introduction
Cybot
OSCAR
Problem Statement
Focused on OSCAR
• Expand OSCAR’s capabilities
–
–
–
–
–
Need
Need
Need
Need
Need
software
better control of motion
to know power usage
to sense environment
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
Project Budgets
Effort and Financial Budget
2286
Estimated
$1,024
1876
Actual
$851
Effort (hours)
Financial ($)
Software Team
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
End Product
Description
• 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
Assumptions and
Limitations
• 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
System Overview
Voice Command
Web Browser
Voice Recognition
Software
Java Server
Pages Code
Drivers
OSCAR’s
Keyboard
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
Technical Approach
• 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
Effort Budget
Effort Budget
Estimated
660
Actual
468
0
100
200
300
400
Hours
500
600
700
Evaluation of
Project Success
Additional
Work
• 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 endeffector subsystem
• Develop demonstration
applications to further
utilize capabilities
• Document future work
• Create additional
diagnostic utilities for
use by other sub-teams
Lessons
Learned
• Very important to test
hardware early
• Learned about:
- Java
- Voice
Technologies
-Web Technologies
-Motion Control
interface
Summary
• 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
Motion Control Team
Motion Control Team
Members:
• Josh Bertram (CprE – 2nd ) – team leader
• Jo-Yi Foo (EE – 2nd )
• Sath Sivasothy (EE – 1st)
• Rius Tanadi (EE – 1st)
Problem
Statement
• Robot movement
• Hardware
broken/unstable
• Incomplete
documentation
Design
Objectives
• Debug and
maintain robots
• Document system
fully
End Product Description
• Working robot
• Documentation
– Conceptual
– Technical
Assumptions and Limitations
• Questioned original assumptions
– Was old software/hardware validated?
• Limitations
– Robot stopped working
– Incomplete documentation
– Robots often used for presentations
Technical Approach
Subsystem “Black Box”
Computer
Motion Control
Subsystem
Motor(s)
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
Financial Budget
Financial Budget
$545
Estimated
Actual
$336
$-
$100
$200
$300
$400
$500
$600
Effort Budget
Effort Budget
Estimated
345
Actual
447
0
50
100
150
200
250
Hours
300
350
400
450
500
Additional Work
• Aid end-effector team
• Develop circuit enclosure
• Tutorial
Lessons Learned
• Debug
– Isolation of variables
– Component validation
• Documentation
– Audience analysis
– Non-technical writing
Summary
• OSCAR works
• Better foundation
– Better documentation
– Better testing procedures
Power Team
Power Team
Members:
• Kiet Nguyen (EE – 2nd) co-leader
• Nick Sternowski (EE – 1st ) co-leader
• Nathan Nguyen (EE – 2nd)
Problem
Statement
• To provide effective
power system support
• Provide a 5 Volt, 2
Ampere source to
sensor team
• Determine power
budget
Design
Objectives
• 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
Assumptions & Limitations
• 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
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
Battery Monitor
Power Supply for Sensor Array
Financial Budget
Financial Budget
$150
Estimated
Actual
$183
$-
$20
$40
$60
$80
$100
$120
$140
$160
$180
$200
Effort Budget
Effort Budget
Estimated
195
Actual
205
0
50
100
150
Hours
200
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
Lessons Learned
• Communication with other groups
• Documentation for future teams
• Selection of voltage regulators
• Documentation provided by
manufacturers
Sensor Team
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)
Problem
Statement
• Provide sensing
capabilities
• Finish sonar system
– Design software for
sonar system
– Integrate hardware
components
– Documentation
Design
Objectives
• Modular design
• Future expandability
• Software interface
• Accurate and reliable
End Product
Description
Assumptions and
Limitations
• Eight individual
distance measuring
sensors
• Appropriate power
can be provided
• Accurate from 40 cm
- 10 m
• One sonar fires at a
time
• Limited memory
available for data
logging
• Simple computer
interface
• Capable of logging
data
• Modular design
Technical Approach:
Hardware
Sensor
Driver Board
Micro-controller
Computer Interface
Technical Approach:
Hardware
to microcontroller
Technical Approach:
Hardware
Computer
Interface
Ribbon
cable to
driver
boards
Microcontroller
Multiplexer
Completed system
Technical Approach:
Software
• Modular
• Interface Protocol ATN
Command
Operand(s)
1 byte
1 byte
1 byte
• Commands -
• Single fire (FireRaw)
• Multiple fire (FireFilter)
• Micro-controller Reset
Additional
Work
• Implement sonar
grid
• Develop
transducer cones
• Develop sonar
analysis software
• Other sensors:
– End-effector
– Temperature
– Compass
Evaluation of
project success
• Sonar software
system implemented
• Systems integration
successful
• Accurate and
reliable ranging
system
• Budgets
Financial Budget
Financial Budget
$34
Estimated
Actual
$37
$-
$5
$10
$15
$20
$25
$30
$35
$40
Effort Budget
Effort Budget
Estimated
294
Actual
324
0
50
100
150
200
Hours
250
300
350
Lessons
Learned
• Gained practical
experience with:
– Sonar hardware
– Firmware
– Programmable Logic
Devices
– PCB design and
manufacture
Summary
• OSCAR’s sensor
system is fully
functional
• Environmental
feedback is available
for the first time
End-Effector Team
End-Effector Team
Members:
•
•
•
•
•
•
•
Tim McCormick (CprE – 2nd ) – team leader
Linda Lua (EE – 2nd )
Mike Taylor (ME – 2nd)
Jet Ming Woo (EE – 1st)
Stephen Shi (CprE – 1st)
Mark Bly (ME – 2nd)
John Cao (ME – 2nd)
Problem
Statement
Design
Objectives
• OSCAR needs an
end-effector
• Basic physical
features of arm
identified
• Decide on details of
implementation and
create detailed
design of arm
• Build 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
Technical
Approach
Assumptions and
Limitations
•
•
•
•
•
Limited time and
budget
Developed over several
semesters
Limited manufacturing
experience
Limited power
consumption
Must run on 12 Volts
and 1.5 amps
•
•
•
•
•
•
Develop a concept for
the design of the arm
Analysis of design
Specification of
components
Develop detailed
drawings and
schematics
Develop software and
electronic control
circuits
Assembly and testing
Gripper Control Design
• Using Stepping Motor
• Control software in
Java
• Stepper motor
controlled by L/R drive
card
• Higher torque
• Smaller size
• Increased functionality
• Capable of future
modifications
• Microstepping
• Position encoders
Gripper Design
• Stepper actuator
– Inexpensive
– Compact
– Linear drive without
transmission
• Linkages easy to
manufacture
• Interchangeable
fingers
• Base easily attached
to arm
Overall Design
• Arm will pivot on topcenter of OSCAR
• Aluminum links
• Driven by Pittman DC
motors
• Joints use modular
worm gear assembly
• CAD drawings of
entire arm (excluding
wrist) completed
Worm Gear Drive Design
• Pittman DC motor
– Reliable
– Reduced speed
– Readily available
• Worm assembly
– Perpendicular
transmission
– Dramatic torque
gains
– No back drive – save
power
• Modular design
– Easy manufacture
– Repeatable spares
Evaluation of
Project Success
• Complete detailed
design of arm - MET
• Detailed drawings of
completed arm - MET
• Complete plan for future
work – PARTIALLY MET
• Develop control circuits
for the hand - MET
• Develop control
software for the hand –
PARTIALLY MET
Additional Work
• 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
Financial Budget
Financial Budget
Estimated
$295
Actual
$295
$-
$50
$100
$150
$200
$250
$300
$350
Effort Budget
Effort Budget
Estimated
690
Actual
534
0
100
200
300
400
Hours
500
600
700
800
Lessons
Learned
• Researching as
much as possible
before deciding on
implementation
• Don’t reinvent the
wheel
• Working with
people from other
disciplines is
rewarding
• Communication is
critical
Summary
• Hand assembly
completed
• Worm gear
assembly detailed
• Overall design of
entire arm
completed
• Future work
planned for the
completion of arm
Project Summary
Lessons Learned
• What went well?
– Communication
• Weekly meetings
• Three-tier organization
– Progress
• Teams met most or all of goals
• What could have been better?
– Ramp-up
• Lost time in first 3-5 weeks
– Report generation process
Summary
• OSCAR closer to autonomous
– Core software in place
– Can sense environment
– Halfway to completed arm
• Better foundation
– Better understand motion control
– Know power consumption
Questions?