P07301: Vehicle Data Acquisition (DAQ) Subsystem
/public/

Project Readiness Package

Table of Contents

This document describes and serves as a template for preparation of a Project Readiness Package.

The objective of the Project Readiness Package is to document:

It will serve as the primary source of information for students necessary during Phase 0 (Planning) to develop a SD I plan and schedule including specific deliverables and due dates. The Project Readiness Package will also support Faculty evaluation of project suitability in terms of depth, scope, and student / faculty resources by discipline.

Administrative Information

Proposal Number
Project Name: Vehicle Data Acquisition (DAQ) Subsystem
Project Number: P07301
Track: Systems and Controls
Start Term: Fall 2006-1
End Term: Per Team's availability Winter 2006-2 or Spring 2006-3
Faculty Guide: Reddy (pvreee@rit.edu)
Faculty Consultant: Slack (gbseee@rit.edu)
Customer organization: KGCOE
Customer contact information: Dr. Hensel 475-7684, echeme@rit.edu.
Principal sponsor: Harris

Change Control

Page # Date Change Description Individual
2 of 7 10/02/2006 Change Analog Outputs from 24 to 8. George Slack

Project Continuation

Project Overview

The Data Acquisition (DAQ) subsystem is one of a family of subsystems to support planned and future vehicular and robotic platforms, specifically P07201, P07202 and P07203 Senior Design projects for current projects. The goal of the Data Acquisition Subsystem Team is to design, build and test Electronics and associated Code to support missions from various KGCOE faculty and student vehicular and robotic clubs and events in the future without the need to redesign. This project shall be sufficient robust to enable scalability, programmability, reusability and reliability.

Staffing Requirements

Discipline Number of Students Skills Required
EE 4 Analog and Digital data acquisition control, Signal Conditioning Daughter Boards, Power Circuitry and Performance Architecture, Interface between Vehicle PC 104 DAQ and PC104 Processor.
CE 2 Linux O/S (or similar) & DAQ Functions Software, Client Network Driver interface (PC104 Processor PCB to external PC)

Continuation, Platform, or Building Block Project Information

N/A

Principle Sponsor or Sponsoring Organization

KGCOE departments: Mechanical, Electrical and Software Engineering.

Detailed Description

To design and develop a robust and reusable PC104 DAQ PCB and software to support Analog and Digital sensors for future vehicles and robots. The project design will be scalable to support to support 10 Kg and 100 Kg weight vehicles. The PC104 DAQ should be designed to support the eventual use from 1000 Kg weight vehicles but can not be thoroughly tested since these motors and associated sensors will not be available. Also, the DAQ PCB will monitor down to 1kg robots. (Current and future platform categories are 1000 kg, 100 kg, 10 kg, 1kg weights.) The DAQ PCB is one of a family of subsystems to support planned and future vehicular and robotic platforms. The goal of the DAQ Subsystem is to design, build and test I/O Circuits, Sensor interface and associated Diver Code. In order to support a wide range of vehicle platforms, this project shall be scalable, programmable, reusable and reliable. The driver code shall form the foundation for future projects that are specific to software applications and future actuator devices.

Customer Needs

PC104 Platform Architecture

DAQ Controls

Function Channels Range Performance Resolution Notes
Analog Voltage 24 0-12 v 20 K sps/ch 12 bit
Analog Voltage Outputs 8 0-5, +/-15V 100hz/ ch 12 bit Sink and source 10ma/ch.
Analog Current Outputs 8 4-20 ma 100hz/ ch 8 bit Current Loop and Voltage compliance
Digital Outputs 16 (min) TTL/CMOS 100hz/ ch na Sink and Source 10ma/ch. Footnote
Digital Inputs 16 (min) TTL/CMOS 100hz/ ch na Presumed to interface to external conditioning circuitry.
Footnote = devices may be Solid State Relay, Optical Isolator or other vehicle control devices.

Temperature Signal Conditioning

1. Each daughter board will have 8 channels.

2. Two temperature daughter types are:

3. Load Cell daughter board for 4 pressure sensor types. Contact Customer for ranges.

Board Performance

Power Requirements:

Client Interface

Other actuator functions

Customer Deliverables

SDI: Proposed concepts and planned final design for customer review and approval, final detailed design concept for customer approval. At a minimum, PC-104 based system should be created that conditions and gathers various vehicle sensory devices and demonstrates proposed functionality. Software and hardware architectures should be defined and documented and necessary development systems specified including cost and availability. Preliminary test plan to be conducted and approved by Customer at time of final delivery will be completed and approved.

SDII: Prototype that has been tested with final user, requirements met and verified as per documented test plan. Design Manual that future teams can apply to their project without the need to rethink this Controller.

Customer and Sponsor Involvement

Sponsor: provide funding. Customer: provide input on his own needs and capabilities regarding the project, provide access to sensors and devices for team to apply to their design. Very involved in the day to day activities from both a customer needs to design to final debugging and demonstration.

Regulatory Requirements

At Customer's direction, team may need to research club or event rules.

Project Budget and Special Procurement Processes

All expenditures will be paid by KGCOE.

Intellectual Property Considerations

None. Project design will be open sourced on RIT website.

Engineering Specifications

NA

Safety Constraints

NA

Detailed Course Deliverables

SDI

Objective: Following the product development process, develop customer needs and engineering specifications, evaluate concepts, resolve major technical hurdles, and employ rigorous engineering principles to design an alpha prototype. Develop a design verification plan and fully document design.

1. Phase 0 Planning: SDI project plan / schedule including specific deliverables and due dates (wks 1-3)

2. Phase 1 Concept Development: Detailed, quantitative target specifications mapped to customer needs. (wks 1-3) 3. Phase 1 Concept development: Develop multiple concepts (on paper) and select most feasible. Update specifications. Customer Feedback. (wk 4)

4. Phase 2 System-Level Design: System design including architecture, sub-system definition, interface definition, and more detailed specifications. Appropriate engineering analysis including hand calculations and simulation / modeling. Determine greatest challenges / risks to project (wk 5)

5. Phase 2 System-Level Design: Proof of concept breadboard, brassboard, or simulation of high risk technologies defined in 4. Use appropriate discipline specific methods to demonstrate confidence in selected architecture / design approach. Design review including risk assessment for technology / cost / schedule. (wks 6-7)

6. Phase 3 Detail Design: Detailed design to meet all customer needs. All long lead items should be identified for ordering. Design review. (wks 8-9).

7. Phase 3 Detail Design: Detailed test plan with linkage to engineering specifications and customer needs. The results of this plan should demonstrate the design meets all customer needs and translated engineering specifications (both high level specifications and cascaded sub-system specifications). (wk 10)

8. Phase 3 Detail Design: Project plan for SDII (wk 10).

9. Phase 3 Detail Design: Project review (wk 10).

SDII

Objective: Following the product development process, build an alpha prototype and demonstrate performance meets specifications. Fully document alpha design and verification testing.

1. Phase 3 Detail Design: Finalize full system design. Design review. (wks1-2)

2. Phase 4 Testing and Refinement: Full feature / function alpha prototype (wks 3-6)

3. Phase 4 Testing and Refinement: Design Verification testing. Execution of detailed test plan with results documented. Design Review and prototype demo. (wks 7-8)

4. Phase 4 Testing and Refinement: Design History File completion (EDGE web site). Generation of conference paper and poster that cover customer needs, specifications, highlights of design, results of design verification testing, and future work. (wk 9)

5. Phase 4 Testing and Refinement: Project review (wk 10)

6. Phase 4 Documentation: Product Manual.

Overall Deliverables

Deliverables Breakdown

Preliminary Work Breakdown

EE - Analog and Digital data acquisition control

EE - Signal Conditioning Daughter Boards

EE - Power Circuitry and Performance Architecture

EE/ CE - Interface between Vehicle PC 104 DAQ and PC104 Processor

CE - Linux O/S (or similar) & DAQ Functions Software

CE- Client Network Driver interface (PC104 Processor PCB to external PC)

Grading and Assessment Scheme

For general guidelines, see https://edge.rit.edu/content/Senior%20Design%20I/public/Grading.

Grading will be as indicated on the standard grade form. Additional graded deliverables specific to this project include a complete Product Manual. These will be included in the Deliverables category for SDII.

SD I

Average expectations ( C ) System functional specifications, software and hardware engineering specifications, software and hardware architecture development, proposed selection of hardware and software development materials and tools, completed test and verification document.

Above average expectations ( B ) Average expectations plus PC 104 control software and hardware designs (flowcharts, software specifications, schematics) feasibility assessment documenting the optimal design based sound engineering and prototype empirical data and power/lifetime estimates, baseline software that demonstrates interaction with sensors and devices, completed bill of materials suitable for ordering necessary development materials and tools.

Excellent ( A ) Above average expectations plus demonstration of Client PC and/or PC 104 Application Software that will not only control but will also monitor and log sensor functions. Design warning indicators or messages that indicate input devices are running outside its control parameters (i.e. temperature, speed and so on). DAQ functions will be designed to be sufficiently flexible to monitor expected larger vehicles that are proposed for future use. Apply or test using a commonly available Graphic User Interface Application running on an external PC (or PC104) that can analyze and present data.

SD II Average expectations ( C ) Prototype system that meets functional requirements according to relevant test specifications that demonstrates proof of concept.

Above average expectations ( B ) Average expectations plus implement design functions from the ( B ) description above SD I.

Excellent ( A ) Above average expectations plus implement design functions from the ( A ) description above SD I.

Three-Week SDI Schedule

Required Resources

Faculty/Consultants
Source Description Available
RIT will be the principal contact person for the Team, will meet with the team weekly, will meet with individual members as needed, will be actively engaged in the design and review processes. G. Slack Yes
RIT will meet with the team weekly, will meet with individual members as requested by student, will be actively engaged in the design and review processes. Dr. Reddy, Consultant. Yes
Customer
Source Description Available
RIT will clarify requirements, interpret and consider trade-offs. Dr. Hensel Yes