Team Contract Fulfillment :: ECE 445 - Senior Design Laboratory

Team Contract Fulfillment


The team contract fulfillment assignment is a document describing whether the obligations set out in the team contract were met. Project groups should write no more than 2 pages double spaced. This document should have five brief sections each of which corresponds to a section in the team contract:

Project Goals: This section should begin with a short description of what you planned on building at the start of the semester. What were the goals of your project? You should elaborate on whether these goals were met.

Expectations: This section should address whether the expectations set in the “Expectations” section  in your team contract were met. Essentially, were the ground rules your team set out at the start of the semester followed?
Roles: At the beginning of the course, your team outlined roles as part of the team contract. Please describe what your roles are now and–if your roles changed–how they evolved as the semester progressed. Did you assign a leader? Were pieces of the project tackled as a group or individually? Why?
Agenda: How did your team make decisions about the project? How were goals set? When an issue with the project came up, how did your team plan to fix it?
Team Issues: This section should cover team-related issues that your group encountered during the course. What sort of problems did you run into? How were they dealt with? Was the process set out in the team contract followed?  In hindsight could you have done things differently to have a better team experience?

Requirements and Grading

Each section is worth 4 points. Points are awarded based on thoroughness. A section that adequately addresses the questions above will receive 4 points.

Submission and Deadlines

The team contract fulfillment document is a group assignment and should be submitted on canvas before the deadline listed on the Calendar.

Control System and User Interface for Hydraulic Bike

Iain Brearton

Featured Project

Parker-Hannifin, a fluid power systems company, hosts an annual competition for the design of a chainless bicycle. A MechSE senior design team of mechanical engineers have created a hydraulic circuit with electromechanical valves, but need a control system, user interface, and electrical power for their system. The user would be able to choose between several operating modes (fluid paths), listed at the end.

My solution to this problem is a custom-designed control system and user interface. Based on sensor feedback and user inputs, the system would change operating modes (fluid paths). Additionally, the system could be improved to suggest the best operating mode by implementing a PI or PID controller. The system would not change modes without user interaction due to safety - previous years' bicycles have gone faster than 20mph.

Previous approaches to this problem have usually not included an electrical engineer. As a result, several teams have historically used commercially-available systems such as Parker's IQAN system (link below) or discrete logic due to a lack of technical knowledge (link below). Apart from these two examples, very little public documentation exists on the electrical control systems used by previous competitors, but I believe that designing a control system and user interface from scratch will be a unique and new approach to controlling the hydraulic system.

I am aiming for a 1-person team as there are 6 MechSE counterparts. I emailed Professor Carney on 10/3/14 and he thought the general concept was acceptable.

Operating modes, simplified:

Direct drive (rider's pedaling power goes directly to hydraulic motor)

Coasting (no power input, motor input and output "shorted")

Charge accumulators (store energy in expanding rubber balloons)

Discharge accumulators (use stored energy to supply power to motor)

Regenerative braking (use motor energy to charge accumulators)

Download Competition Specs:

Team using IQAN system (top right corner):

Team using discrete logic (page 19):