Problem Definition & System Design

Team Vision for Problem Definition Phase

The project objectives were elaborated in detail to come up with a problem definition which satisfies all parties. Customer interviews were held, and engineering requirements were drafted. House of quality analysis was performed and use case scenarios were drafted.

Project Definition

An Inflatable Robotic Hand is a portable, mountable device that can inflate, manipulate an object, and deflate remotely. The system will be house in a container mounted on a RC car. This device will utilize some of the same principles, specifically the air muscles, used in previous RIT senior design projects P14253P09023P08023, and P08024. This project will add the ability of inflating out of a small container.

The goals of this project are to analyze previous air muscle designs, and other inflatable robot technologies, to identify an opportunity to combine these ideas into one product. The expected results is a functional prototype that can be applied to the task. The prototype must use air for generating actuation forces while resembling a hand with a minimum of three fingers.

1 Page Project Summary

Use Case

Use Case Scenario Flow Chart
Shows use case where user picks up a tennis ball

Project Goals & Key Deliverables

  • The arm, hand, and vehicle can be remotely controlled by user
  • Pick up a tennis ball
  • Mounted on an RC vehicle
  • Inflate out from a compartment
  • Actuation force is produced by air muscles

Customer Requirements (Needs)

Purpose

To decompose the Problem Statement into functions of elements needed to satisfy the customer.

Customer Requirements

Rqmt #ImportanceDescription
C0019Must use air for inflation and actuation forces
C0029Must be able to pick up a tennis ball up to 2 in off the ground
C0039Must resemble a hand or fingers
C0049Must inflate from a container housed on an RC vehicle
C0053Must deflate fully back into the container
C0069Must be remote controlled
C0079Material selection must withstand inflation/deflation cycles without popping or tearing
C0083Use a single controller to control both the robotic arm and the RC vehicle
C0093Prototype and final model must be built with a $750 budget
C0103Move object (tennis ball) from one location to another
C0111Mounted camera for targeting and navigation

Inputs

  1. PRP
  2. Problem Statement
  3. Customer Interviews
  4. Art North & Dr. Lamkin-Kennard.

Outputs

Customer Requirements

Engineering Requirements (Metrics & Specifications)

Purpose

Create a contract between the engineer and the customer where indisputable satisfaction of the engineering requirements equates to customer satisfaction

Engineering Requirements:

Rqmt #ImportanceEngineering RequirementUnitTarget ValueMarginal Value
0011Air compressor powerpsi> 120100
0029Air compressor flow ratescfm> 0.880.3
0039Inflation timesec< 25
0043Deflation timesec< 1015
0053Inflation arm reachin> 64
0061Object lift distancein> 64
0079Hand grip strengthpsi> 2015
0083Stored air volumeml> 1200200
0093Stored air pressurepsi< 10080
0109Number of fingers on robotic handunits= 33
0119Battery lifemin> 9030
0123Chassis load weight capacitylb< 40120
0139Chassis surface mount areain^2< 24x2430x30
0143Arm container cross-sectional areain^2< 6x68x8
0151Arm container heightin< 810

Inputs and Source

  1. PRP
  2. Dr. Lamkin-Kennard
  3. Art North

Outputs and Destination

  1. HoQ

Constraints

From Customer Requirements

  • Inflation mechanism must use air only
  • Robotic arm and hand must fit inside a small container

From Engineering Requirements

  • Weight of robotic arm, air compressor, tank, and control systems must not exceed chassis weight capacity
  • Must have large enough power source to supply power to the motors, compressors, and control systems

House of Quality

public/Problem Definition Documents/HoQ.PNG
public/Problem Definition Documents/HoQ_Legend.png

Inputs and Source

  1. PRP
  2. Customer Requirements
  3. Engineering Requirements
  4. Benchmarking Data

Outputs and Destination

Design phase

Team Vision for System-Level Design Phase

Our plan was to develop the functional decomposition of our system, come up with possible solutions, and out line the system architecture. We also planned on benchmarking the different components and analyzing the feasibility.

We were able to complete all of the tasks we set forth to do for this phase.

Functional Decomposition

alt text

Benchmarking

Benchmarking

Morphological Chart and Concept Development

Morphological Chart

Concept Selection

Concept Selection & Pugh Chart

Systems Architecture

alt Text

Feasibility: Prototyping, Analysis, Simulation

Feasibility

Risk Assessment

Updated Risk Assessment