Ongo-01c

OSCAR power sub-team

Fall 2003 Project Plan

Version 2.0

Client:

Department of Electrical and

Computer Engineering,

IowaStateUniversity

Faculty Advisor:

Dr. Ralph E. Patterson III

Team Members:

Marquis, Daniel / Nguyen, Hong

10October 2003

1

Ongo-01c

OSCAR power sub-team

Revision History
Date / Author / Description / Version
22 September 2003 / D. J. Marquis / Document Inception / 1.0
26 September 2003 / D. J. Marquis / Document Revision / 1.5
26 September 2003 / D. J. Marquis / Document Revision / 1.6
2October 2003 / D. J. Marquis / Document Revision / 1.7
9 October 2003 / Hong Nguyen / Document Revision / Corrections / 1.8
10 October 2002 / D. J. Marquis / Document Revision / Corrections / 1.9
10 October 2002 / Hong Hguyen / Document Revision / Corrections / 2.0

Ongo-01c

OSCAR power sub-team

Table of Contents

1.Introduction

1.1Abstract

1.2Acknowledgement

1.3Problem Statement

1.3.1Primary Problem

1.3.2Secondary Problem

1.3.3Tertiary Problem

1.4Operating Environment

1.5Intended Users and Uses

1.6Assumptions and Limitations

1.6.1Assumptions

1.6.2Limitations

1.7Expected End Product

2.Proposed Approach and Statement of Work

2.1Functional Requirements

2.2Design Constraints

2.3Technology Considerations

2.4Technical Approach Considerations

2.5Testing Requirements Considerations

2.6Security Considerations

2.7Safety Considerations

2.8Intellectual Property Considerations

2.9Commercialization Considerations

2.10Possible Risks and Risk Management

2.11Proposed Project Milestones and Evaluation Criteria

2.11.1Find DC-DC Converters

2.11.2Create Power Budget

2.11.3Verify Battery Status

2.11.4Verify Battery Indicators

2.11.5Test DC-DC Converters

2.11.6Fuse protection

2.11.7Research for Temp Sensor Power Solution

2.11.8Built & Installed Temp Sensor Power Solution

2.11.9Test Temp Sensor Power Solution

2.13Statement of Work

2.13.1Problem Definition

2.13.2Technology and Implementation Considerations and Selection

2.13.3End-product Design

2.13.4End-product Prototype Implementation

2.13.5End-Product Testing

2.13.6End-Product Documentation

2.13.7End-Product Demonstration

2.13.8Project Reporting

3.Estimated Resource Requirements and Schedules

3.1Estimated Resource Requirement

3.1.1Financial

3.1.2Personnel Effort

3.2Schedules

4.Project Team Information

4.1Client information

4.2Faculty advisor information

4.3Team member information

5.Closing Summary

Table of Figures

Figure 31 – Power sub-team schedule of tasks

Figure 32 – Power sub-team schedule of deliverables

Table of Tables

Table 21 – Power sub-team measurable milestones

Table 31 – Power sub-team financial budget

Table 32 – Power sub-team personnel effort budget

Table 33 – Power sub-team major tasks schedule

Table 34 – Power sub-team deliverables schedule

List of Definitions:

DC-AC inverter=An electronic device that changes DC current to alternating current, usually to simulate a regular household wall socket power supply.

DC-DC inverter= An electronic device that changes a DC power supply's voltage level to a different voltage level, usually to meet power supply specifications of a load.

OSCAR = Octagonal Speech Controlled Autonomous Robot

1

Ongo-01c

OSCAR power sub-team

1.Introduction

Project OSCAR (Octagonal Speech Controlled Autonomous Robot) is an ongoing senior design project funded by the Department of Electrical and Computer Engineering (ECpE) at Iowa State University (ISU). Its purpose is to maintain and improve robotic ambassadors for the department. Past robots include Zorbaand CYBOT. The most recent robot is OSCAR.

None of the robots are completely operational at the moment. Zorbano longer exists. CYBOT is aging and no longer works. OSCAR is in need of some new hardware, some new software, and a new power supply.

The power sub-team is a part of Project OSCAR. The power sub-team has beentasked with solving OSCAR’s power supply problems, which have helped prevent it from giving effective demonstrations and fulfilling its role as a departmental ambassador to the community.

Recent power supply problems resulted from a change in computer hardware. In Spring 2003, a new computer was installed that consumed 300% the power of the old computer. This caused a DC-DC converter that was built that semester to be overloaded and never fully implemented. This semester, however, a more energy efficient computer (PC 104) will be installed and the DC-DC converter should, once again be sufficient.

1.1Abstract

The robot OSCAR, whose purpose is to serve as an ambassador to the public for ISU's department of ECpE, is unable to give significant demonstrations. This inability is partially due to an inefficient power supply. To solve this problem,an efficientDC-DC converter was designed and built over a year ago. It was to power the main system components and replace OSCAR's inefficient DC-AC-DC powersupply system. Unfortunately, due to various difficulties,the DC-DC converter was never fully installed and tested. The Fall 2003 power team's goal is to finish installation and testing of the DC-DC converter and to provide at least a temporary on-board power solution to any subsystem not served by the DC-DC converter.

With a completeand more efficient power system installed, OSCAR will be one step closer to performing meaningful demonstrations for the public; and therefore will be one step closer to fulfilling its role as an electronic ambassador.

1.2Acknowledgement

The help of the OSCAR project advisor, Prof. Patterson, and the cooperation of otherOSCAR sub-teams will prove indispensable to the success of the OSCAR power sub-team’s part of the project.

1.3Problem Statement

Below are the two problems the power sub-team hopes to solve this semester.

OSCAR’s power comes from two 12-Volt rechargeabledeep cycle marine batteries stored in its base. Unfortunately, OSCAR's computer and other electronic devices can't be directly hooked up to the batteries because they require different voltages (5V, 6V, 20V). To solve this problem in the past, a 12/120 DC/AC inverter was used to convert the batteries' 12V DC into a standard household 120V AC. Then AC/DC converters (those black boxes one plugs into a wall outlet) were used to convert the power back to DC, but at the needed voltages.

While the above process works, it is very wasteful of power. Therefore, to reduce power loss and maximize the amount of time OSCAR can run between charges, a more efficient DC-DC converter was made a year ago. Due to a massive increase in power requirements, however, the new DC-DC converter was deemed insufficient and never implemented. Now, however, the power requirements may decrease due to hardware changes, and the DC-DC converters may be sufficient to power OSCAR.

OSCAR needs a complete and efficient power supply. One was built a year ago, but the addition of a new computer increased power requirements beyond the supply's capability, so the supply was never implemented. Now, however, the software sub-team is planning to install new hardware that will probably decrease power requirements enough for the DC-DC converters to supply it.

Problem:

AC-DC-AC is inefficient

Sensors has not been incorporated into OSCAR's on-board power supply.

Supply was build 1 year ago. However, newly installed hardware drew more current than the supply was designed for. Therefore, it was only partially tested and never implemented.

Supply was built, but not implemented 2 years ago, but it doesn't output the voltages needed by sensors and was never fully tested and implemented into OSCAR. The reason it wasn't

Solution:

Finish testing

1.3.1Primary Problem

Currently OSCAR is running a PC that uses a standard PC power supply. This supply is fed from a 12/120 DC/AC inverter. The inverter is powered by two twelve-volt, on-board batteries. The power sub-team views these two power supplies as a wasteful part of OSCAR. The power that OSCAR has on-board is very limited. The goal is to minimize the losses in this subsystem (the PC) in order to save as much power as possible.

This will be accomplished by first doing a power audit on OSCAR to verify that its current/future power needs can be met with the previously built DC-DC converter. If so, the DC-DC converter shall be tested and installed. If not, then an alternative shall be considered, and the project plan rewritten.

1.3.2Secondary Problem

Currently, OSCAR's sensors are not connected to an on-board power supply; instead they are being powered by the wall outlet, which effectively requires OSCAR to be tethered at all times. Since OSCAR is an Autonomous Robot, this is unacceptable, and an on-board power supply must be implemented.

This will be accomplished by a)finding and implementing a quick and easy way to supply sensors with on-board power, b) implementing such a quick fix, and c)starting to research a more permanent solution.

Depending on workload, the sensors sub-team may take the lead in solving this problem.

1.3.3Tertiary Problem

Maintenance and support for the existing power system must be provided so that other teams can test parts of OSCAR.

1.4Operating Environment

OSCAR is designed to operate in controlled, indoor environments. Exposure to excessive dust, EM radiation, heat, and physical abuse should be avoided. OSCAR is computer-based and its operating environment constraints are largely set by the operating environment constraints of its electronic components. An occasional drop or fall may occur, but should not be disabling.

1.5Intended Users and Uses

The power system is intended to serve all systems on board OSCAR. This includes the motion control team and their six DC motors, the sensor team and their sensor array, the software team and the on-board computer, and finally the end-effector team and the future arm they will provide.

The power system is intended to supply power to OSCAR for demonstrations. These demonstrations last five minutes, fifteen minutes, half an hour, or even a few hours. The power system is not intended to provide power to non-related devices like home theater systems, full fledged desktop computers, electric lawn mowers, and halogen lamps.

1.6Assumptions and Limitations

Below are the assumptions and limitations the power sub-team used in creating its project plan.

1.6.1Assumptions

  • OSCAR’s use will be limited to its general current demonstrative capacities.
  • Sensitive power systems will be isolated. For example, the PC and sensors will not run off the same supply line as the motors.
  • Power requirements will not increase substantially without the power sub-teamsfirst being notified and consulted so that adjustments can be made.
  • Demonstrations will be late in the semester, if they take place at all.

1.6.2Limitations

  • Power supplied can not exceed the batteries' ability to furnish power.
  • Batteries are in good working order.
  • The previously built DC-DC converters and sufficient documentation must be found.
  • The ability of the DC-Dc converter to supply power is limited.
  • DC-DC converters are in good wording order.
  • The amount of time that each member can invest into the project is limited.
  • There are only two members on the power sub-team this semester. This will require more time from each sub-team member in order to build the supplies, write reports, attend management meetings, and do presentations and demos.
  • The power sub-team budget is currently $0; therefore, spending money should be avoided if at all possible.

1.7Expected End Product

The expected outcomes of this sub-team's project are:

1) a DC-DC power supply system for the computer

2) a power budget for OSCAR

3) a temporary on board power supply for sensors

1

Ongo-01c

OSCAR power sub-team

2.Proposed Approach and Statement of Work

Below are the requirements, constraints, considerations, milestones and end-product issues the power sub-team has selected.

2.1Functional Requirements

  • Power quality: Computer quality, +/-5V power must be supplied to the computer.
  • Peak power availability: The amount of peak power available must exceed the maximum possible peak load (i.e. the load if all OSCAR systems were to perform their most power intensive processes at once).

2.2Design Constraints

  • Maximum power capability: Hours @ Ampere Load for 2 batteries working together are 11.6hr@5A; 3.2hr@15A; maximum capability of batteries is 110 Ampere-hours.
  • Minimum battery charge:battery should not be discharged below 50% (i.e. 12.24V) for any extended period of time (if possible). Damage may result.
  • Operating conditions: OSCAR is intended to be used autonomously. Consequently, maximum battery life is required.
  • Weight: all components must be as light as practical to allow for easier transportation of OSCAR and as to not over-work the motors and conserve energy.
  • Size: both robots feature relatively small volume inside their cases. Components must be designed to fit within the case.

2.3Technology Considerations

The technologies to be used for the DC-DC converter have already been chosen and implemented. The technologies to be used for incorporating the sensors might include: rechargeable batteries, a DC-AC-DC converter system, and a DC-DC converter.

2.4Technical Approach Considerations

The technical approach used for choosing a temporary power supply for sensors (and any other system not hooked up to the DC-DC converter) will be quick. A solution will be searched for and evaluated based mainly on how quickly the solution can be implemented. In no case shall the solution cause demand for power to exceed available supply.

2.5Testing Requirements Considerations

The technical approach used for testing the DC-DC converter shall be systematic, incremental testing. The power supply shall be tested on its own for power quality, and voltage levels. Then every OSCAR subsystem shall be tested for shorts and be fused. Finally, OSCAR shall be tested with the battery installed one subsystem at a time and then all together.

2.6Security Considerations

Security is not a big concern for this project, though locking the senior design lab door is a very good idea.

2.7Safety Considerations

Batteries should not be pried open or exposed to excessive heat. Leakage of acid may result.

2.8Intellectual Property Considerations

Currently, the power sub-team is not aware of any intellectual property considerations. The only possibleexception is the DC-DC converter design, which was pulled off the web. The design, however,seems to have been made for public use.

2.9Commercialization Considerations

There are no plans to commercialize OSCAR's custom built power supply.

2.10Possible Risks and Risk Management

  • Short circuit: (Risk level = Moderate)

A short circuit may occur from components of other sub-teams. Protecting each sub-system individually will solve this problem. Resistance measurements will be made at the supply terminals for each sub system. This will provide the sub-team with the information to set up protection for the short circuit current.

  • Non availability of parts: (Risk level = Low to Moderate)

If the power sub-team has to order parts and if the parts for the supply are not available, a delay will occur. Alternate sources may be available for parts, but it would take time to locate the alternate vendors. Multiple vendors will be considered to buy the parts from.

  • Cost Risks : (Risk Level = Moderate to High)

The power sub-team has a budget which does not allow replacement parts due to items being lost or stolen or broken. The risk level is Moderate to High, because the DC-DC converters are missing at the moment. To mitigate this risk the power sub-team shall make every effort to find any missing equipment and to lock up the Senior Design lab.

  • Having an inadequate Power Source: (Risk Level = Moderate)

If other teams increase their power usage without the power sub-team's knowledge, then the power supply may no longer be sufficient to power OSCAR, and demonstrations will not be possible. To mitigate this risk, the power sub-team shall attend all team leader meetings.

  • Over committed team members: (Risk Level = Moderate to High)

The power sub-team members are seniors in electrical engineering at IowaStateUniversity and have very little free time. There is no real way to mitigate this risk. Commitments have already been made for the semester.

  • Uninformed team members: (Risk Level = High)

The power sub-team members are both new to the project, there hasn't been a power sub-team in over a year, and documentation is barely sufficient. There is a high risk of the sub-team members being uninformed. Steps taken to mitigate this risk include: finding all the documentation available and talking to the project advisor. Future steps that will be taken include: contacting former team members and asking questions of second semester students.

  • Loss of team member: (Risk Level = Low)

Since the team is only composed of two people, loosing a member would be detrimental. The member’s knowledge would be lost. The risk to the project from loss of a member shall be minimized through extensive communication between members. This will reduce the amount of knowledge that could be lost.

  • Wrong Approach: (Risk Level = Medium)

Much of the documentation is missing for the DC/DC converters, and that increases the risk of choosing the wrong approach. To minimize the risk of a taking a wrong approach, will find the documentation

2.11Proposed Project Milestones and Evaluation Criteria

Table 21– Power sub-team measurable milestones

Milestone / Priority / Completion
DC-DC Converters Found / High / 20%
Power Budget Created / High / 5%
Battery Status Verified / High / 0%
Battery Indicators Verified / Low / 0%
DC-DC Converters Tested / Medium / 0%
Fuse Protection Implemented / Verified / High / 0%
Temp Sensor Power Solution Researched / Low / 0%
Temp Sensor Power Solution Built and Installed / Low / 0%
Temp Sensor Power Solution Tested / Low / 0%

2.11.1Find DC-DC Converters

Criteria for this milestone shall be 20% founding design, 10% if talked to designer, 60% if found converters, 10% if find spec list. (or if find that spec list doesn't exist)

2.11.2Create Power Budget

Criteria for this milestone shall be 10% for obtaining each sub-team's power requirements/estimates at the beginning of the semester, 10% for producing the initial document, 10% for obtaining each sub-team's power requirements/estimates at the end of the semester, and 10% for having a document at the end of the year. A complete, up to date document at the end of the year will be worth 100%, regardless.

2.11.3Verify Battery Status

Criteria for this milestone shall be 33% each for testing ability to charge, testing ability to discharge, and testing ability to hold charge.

2.11.4Verify Battery Indicators

Criteria for this milestone shall be 25% each for seeing if the charge drain meter is accurate, and 25% each for fixing any problems.

2.11.5Test DC-DC Converters

Criteria for this milestone shall be 25% no load testing of voltage, 25% testing at controlled current, and 50% testing on the robot itself.

2.11.6Fuse protection

Criteria for this milestone shall be solely the installation of fuse protection on all subsystems. Equal weight (25%) will be given for each subsystem requiring power: Motors, Software, Motion Control, and Sensors.