Acknowledgments
We would like to thank the following for donating their time, knowledge, wisdom, expertise, and resources to make this project possible.
Dr. Don Cripps
Dr. YangQuan Chen
Laura Vernon
Juniper Systems Inc.
Dustin Rawlings
Mary Peacock
1. Introduction
Elevators transport people, goods, and services from one location in a building to another location in the same building through vertical motion. Elevators make this transportation easier by taking away the effort needed to walk up stairs or ramps. They are also beneficial in moving heavy objects to different levels, which reduces the possibility of calamity.
Elevators are also useful in transporting disabled people from one floor to another. This use of transporting disabled people, specifically those who are in wheelchairs, reduces the occurrence of accidents. The problem that is now facing those in wheelchairs is that they might not have enough time to get positioned in the elevator before the doors start to close. Once the wheelchair-bound person is inside, they barely have enough room to maneuver to push the floor select button. If there are other people inside, there often isn’t room enough to maneuver.
1.1. Identified need
The problem that wheelchair-bound people face is not having enough control over the elevator. If they were able to control the elevator through means of a mobile device, operation could be greatly simplified.
1.2. Problem Definition
Since this device can be used by everyone, it incorporated both manual and remote operation of the elevator. It incorporated the same numbers and buttons on the device that are on the existing elevator button panel. Through the use of solenoids, the original buttons of the elevator were activated through remote operation. Our design preserved the internal workings of the elevator, allowing the existing safety systems to function correctly.
1.3. Objectives and Deliverables
To meet the needs described above, we designed and built an apparatus that was a working prototype of our design. Our design allowed the elevator to be operated both manually and remotely via a Bluetooth radio signal. Every elevator is unique so our design was applied specifically to the elevator in the Utah State University Engineering Building.
1.3.1. Objectives
The apparatus was placed over the buttons of a specific elevator which allowed the elevator to be operated either manually or through a mobile devise via Bluetooth radio signals. This type of system was designed to minimize the intrusiveness on the existing elevator. The wireless communication between the remote device and the stationary apparatus involved both hardware and software components.
1.3.2. Scope of Work
We investigated the specific needs that were shared by wheelchair-bound people and integrated data obtained into the project. We determined that Bluetooth radio communication best fit the needs of this system. We designed the electro-mechanical device that accomplished our objectives, and implemented software that could be integrated into a wide range of wireless devices, such as cell phones, PDAs, and hand-held computers.
1.3.3. Deliverables
We had a working prototype to show that our idea was feasible. This included the electromechanical apparatus which fit over the panel of the elevator with developed software installed into the microprocessor sub-system and application software that can be installed and executed on handheld devices. The source code for the software of this project is also included as an appendix in this report.
1.3.4. Summary of Design Process
The design process was to first identify the need, secondly, discuss possible solutions with more experienced engineers, third come up with a design and a plan to execute, and finally, build and document the radio-controlled elevator.
Throughout the design process, several set-backs necessitated a need for revisions to our design. One problem that we ran into was the chosen solenoids didn’t have enough force to press the buttons. Another problem was how to supply the necessary power to drive the solenoid. These problems, as well as others, will be discussed in a later portion of this report.
1.3.5. Summary of final results
The final result of the radio-controlled elevator project was that software installed on a mobile device was able to communicate and control solenoids through Bluetooth radio signals. These solenoids, when controlled, push the buttons of the elevator. The light illuminated from the elevator button was used as a signal to drive circuitry that notified the user the button had been pushed. This system also incorporated manual operations where buttons on the surface of the control unit were pushed and the signals from those buttons operated the solenoids in a similar fashion.
1.3.6. Organization and summary of report
This report explains in detail the investigation of different design solutions, the process of analyzing and choosing the best solution for this project, and the execution of building the radio-controlled elevator system.
2. Review of Conceptual and Preliminary Design
2.1. Problem Analysis
2.1.1. Review of problem
In theory, the elevator is the perfect solution for someone who is unable to go up and down stairs. Their design, however, could use some improvements. The size of a standard elevator does not allow enough space for a wheelchair to maneuver with other occupants inside. The buttons are often out of reach for the person in the wheelchair making operation difficult, if not impossible, without assistance. Another problem is that even if they can get close enough, many people in wheelchairs lack the mobility to reach up to press the buttons needed to operate the elevator.
2.1.2. Summary of specifications
Our device incorporated manual and remote operation of the elevator so that it could be used by everyone. The device was thin and fit over the existing elevator button panel. Along with the buttons being the same as the elevator’s original buttons, the device matched the aesthetics, color, and function of the elevator. To accomplish this, an understanding of the materials that make up the elevator was required.
Through the use of solenoids, or some other type of actuator, the original buttons of the elevator were activated through remote operation, while still allowing manual operation. The internal workings of the elevator remained unchanged, thus allowing the existing safety systems on the elevator to function correctly without modification. This also helped to keep the elevator interior looking nice since the device does was mounted to the elevator.
Further investigation revealed there wasn’t really a need for a device to be mounted on the outside elevator panel since there is usually room for wheelchair movement outside the elevator. There could be future development to implement an outside actuator panel since there are people that have mobility handicaps that prevent them from reaching the button.
2.1.3. Discussion of main features of the design problem
The first critical part of the design was the Bluetooth module. This wireless communication allowed control over the elevator through a mobile device. This mobile device was programmed and paired through the standard Bluetooth pass code protocol so that a controlled group of individuals may operate the elevator through radio communication. Bluetooth radio communication was used because of its vast availability in many types of mobile devices.
The second key component to this project was manual operation. Buttons on the outside faceplate allowed for standard button-pushing operation so that those who are not included in the controlled group of mobile device operators were still able to use the elevator.
Another key feature of the project was the nonintrusive nature of the device. Because we did not modify any of the existing elevator components, all existing safety systems remained. This eliminated the need for any sort of safety certification on this device.
The last feature of the project was the ability for us to keep the wireless communication of the device secure so that unwanted control of the elevator is kept at a minimum.
2.1.4. Summary of basic engineering or technical approach
2.1.4.1. Basic design concept
This system included design work in three main areas: mechanical design, electrical design, and software design. The mechanical design of the system was simple because the apparatus looks as similar as possible to the existing elevator buttons. Some mechanical aspects came into play in designing the buttons of the apparatus. The solenoids are placed over the existing buttons of the elevator and allow for manual operation. The electrical design includes a microprocessor system with all power and memory subsystems with an integrated radio transceiver for data communication. It also includes an output subsystem that incorporates circuitry to operate the solenoid actuators. Software for this system is designed to function from a Windows Mobile 5.0 or later operating system. The software includes the needed Windows graphics for the mobile device operation, and functionality for button pushing.
2.1.4.2. Features common to all feasible solutions
The design approach used Bluetooth for data transmission. While Bluetooth wireless data transmission may not be a feature that is common to all feasible solutions, having some sort of wireless data transmission is. The main idea is that a person operates the elevator through some type of wireless signal. Our solution utilized a non-intrusive approach that left all existing elevator systems unchanged. Any solution implemented will have to leave the safety systems on the elevator unmodified as we have.
2.1.4.3. Different Solutions
An area that we ran into problems with was in the power management of our design. There are many different options that we could have chosen. One of them was to use the motion of the elevator to generate power, another was let photocells generate power. These ideas included some type of power storage system. One option was to tap into the elevators power system, but that option was quickly eliminated since one of the requirements was to leave the existing elevator system unaltered. Ultimately we chose to abandon any type of power generating system and operate the system through pre-charged batteries. The complexity of a power generation system would cause the workload of our project to exceed our abilities. Using pre-charged batteries allowed us the most flexibility with a reasonable workload. This method also allowed us to make our design mobile. Our design can be implemented to fit any elevator with only slight modifications. The batteries allow for an expansion or contraction of our design, while the other options are for a fixed design.
Another area that we had problems with was in the area of choosing the right type of solenoid. Finding solenoids that were small enough to fit into our flat design, powerful enough to push the buttons of the elevator, and cheap enough to keep us within our specified budget was a challenge. In the future, there may be a more integrated system that will be included in the overall design of the elevator. This would eliminate the need for solenoids with their accompanying circuitry and the light sensing circuitry as well.
The software for this project was developed to run on a device with a Windows Mobile 5.0 or later operating system. Other solutions might include application software written to operate on additional operating systems.
2.2. Decision Analysis
Throughout this process, we needed to make several decisions on what type of solenoids and electrical components would work best for our needs. We also explored different configurations of these components to accomplish our objectives. This section will outline the processes that we used to make decisions.
2.2.1. Description of solution alternatives
One button pushing layout solution that we explored was to have a solenoid drive a lever arm mechanism. This was investigated to try to increase the force produced by the solenoid to depress the elevator button. This idea was abandoned because the solenoids we investigated had a length of travel too small to implement a lever. We decided instead to have the solenoid press the button directly and have a small spring arranged around the push rod to assist the solenoid and increase the overall force.
Originally we wanted to implement a system that would take the signals of the stationary Bluetooth receiver system and integrate that into the elevator control panel. For safety and security reasons, we felt it better to create our own face plate, and preserve the elevators existing operating systems. Ideally manufactures will incorporate this design into the overall design of the elevator.
2.2.2. Discussion of decision analysis and final decision
We decided to use the spring loaded rod system because it offered the simplest solution. We could have used the solenoid-lever combination, but that would have required a lot more research to make the end goal of pushing a simple elevator button. Another reason for using solenoids by themselves came from the need for a simplistic design. If we had decided to use a lever as a push rod, we have been stretched for time and resources.
Along with deciding on the solenoid, we also needed to find some sort of switch that could handle high currents and high voltages. We considered using relays as the switch. Have a low voltage and current trigger a high voltage and current. This option was not feasible because we were not sure exactly how much current was needed. We could have chosen a relay that was not rated at the right voltage and current rating, which may have resulted in burning the relay and rendering it useless. An alternative solution was to use a high current and voltage capable MOSFET. Once one was found, we had an instant switch with no moving parts. The currents and voltages that we used are well below the rated limit of the MOSFET. We did analysis on the MOSFET to make sure that it works as a switch and not as an amplifier.
Another decision that we needed to make was how to transmit the data from one wireless device to another. We asked ourselves, what type of wireless communication do we use, and how do we use it correctly? These questions and others all had to be answered to the best of our ability before we could proceed with the design.
The decision regarding wireless communication was made with the mindset to make the compatibility as wide as possible. One of the most widely used forms of wireless communication on mobile devices today is Bluetooth. This type of wireless protocol fit perfectly into our design considerations.
Another thing that we needed to decide was how we were going to signal the user that the correct floor has been selected. This came about after we had decided to cover the original face plate with our own. This meant the original light signal would be blocked and the user wouldn’t know what floor the elevator was on. In order to build a light system of our own we needed to build and test a light sensing circuit. One was found and modified so that it could be used in any light setting.
Our final decision we made was how to mount the device to the actual elevator. This was done with the use of double-sided tape and adhesive tape. This allowed us to mount it securely and yet still have it removable when needed.
3. Basic Solution Description
3.1. Schematics and flow sheets defining all system components and their relationships
Figure 11: Overall Flow Diagram
Figure 12: Solenoid Driver Circuit
Figure 13: Light Sensing Circuit
Figure 14: Host Program Flow Chart
Figure 15: Mobile Program Flow Chart
Figure 16: Mechanical Layout
The above flow diagrams represent a portion of the overall workings of the device. Figure 1 shows how everything worked together. Figures 2 and 3 show the electrical circuit diagrams for our device. Figures 4 and 5 show the software flow diagram for our project.
3.2. Discussion of Design Dependencies
The most critical force that we needed to find and overcome was the force of the elevator button. The force needed to press this button was measured to be 10 ounces. Looking on the manufactures website, Ledex, we found a recommendation to increase our needed force by 1.5 times what we had measured. We decided sixteen ounces should be our goal. We then found and purchased some solenoids that met our force requirements.
Our design called for the use of different voltage and currents. For everything except the Solenoid Driver Circuit, we used a voltage of five volts. This allowed for small currents and met our needs in signaling the user of a button push. For the Solenoid Driver Circuit we used a voltage supply of twenty-four volts. This allowed us to draw a current of one and a half amps. This high of a current was required to drive the solenoids with enough force to press the elevator button. Since we used two different voltages in our circuit, we built our project so that each circuit was isolated from the other. This prevented the occurrence of a short circuit.
3.3. Initial system performance estimates
In all cases, the system was initially estimated to perform well, but there were several ways in which the system could fail. One problem we foresaw was that the system may not stay adhered to the elevator panel. Another concern was the design could fail if the batteries didn’t hold their charge long enough. A third concern we had was that the solenoids were not powerful enough to press the buttons. After ensuring these concerns were dealt with, we estimated the system would perform exactly as planned.
4. Performance Optimization and Design of System Components
This system required that all of the different components work together to complete a common goal: control an elevator through the use of wireless communication.
4.1. Components and component-level specifications
4.1.1. Solenoid Driver Circuit
4.1.1.1. Solenoid
The solenoid driver circuit consists of the solenoid, a power MOSFET, a current limiting resistor, and a power supply. The solenoid that we chose to use was a Lucas 195202-331. This solenoid was capable of handling up to 40 watts of power. We found that the higher the voltage and the higher the current, results in a higher output force from each solenoid. The solenoid needed to be a push-type solenoid in order to accomplish our goals. Since the Lucas 195202-331 is a pull-type solenoid we needed to do some creative mechanical configurations in order to get it to work. The mechanical layout of the solenoids will be discussed further in this report.
4.1.1.2. Power MOSFET
The next part in the circuit was the power MOSFET. We chose an N-type MOSFET (IR LR 120N) which can handle up to 10 amperes at about 100 volts. Our system runs between 22 to 25 volts at 1.5 amperes which was under the maximum rating of the MOSFET. For our purposes, a MOSFET that would be able to handle this type of high currents is essential. Most of the MOSFETs that we looked at were not able to handle these high currents. Through research we narrowed our choice down to two or three, but we ultimately chose the IR LR 120N for its price and availability.
4.1.1.3. Current Limiting Resistor
We needed to have a current limiting resistor in our solenoid driving circuit to prevent damaging our solenoids. The solenoids were rated for 40 watts, as stated before. The resistor was there to keep the current low enough so that the solenoid was not destroyed. We found, through testing, that the solenoid required 1.5 amperes of current in order to function correctly. While testing, we used the bench-top power supply for current limiting to measure the current needed to drive the solenoids. Since we have up to about 24 volts on our supply rail, we needed to have a 15 ohm resistor in order to get 1.5 amperes. This translated to a 36 watt power rating for the resistor. We found a wire wound resistor that was rated for 50 watts at 15 ohms which gave us plenty of head room in our design.
4.1.1.4. Batteries
The final part of the solenoid driver circuit was the batteries needed to provide the currents and voltages specified. We used a series of lithium ion batteries. These batteries were able to source enough current while keeping the voltage level within our specified voltage constraints. Each battery pack provided 7.4 volts. We used 3 packs wired together in series.
4.1.2. Light Sensing Circuit
This circuit was used to alert the end user when a button had been pushed. We needed some way to mimic the elevator’s lights, meaning, when the floor indicator light on the elevator turned on and off, a signal LED on our device needed to turn on and off as well. The Light Sensing Circuit detected when the elevator’s floor indicator light came on and off and then relayed that signal to the user. This was done through the use of photocells, operational amplifiers and small resistors.
4.1.2.1. Photocell
The photocell was a standard CdS 202420 resistive photocell. Its function was to change the resistance when light was present. When there was very little or no light, the resistance of the cell was high. As the light intensity increased the resistivity of the cell went down. As the resistivity of the cell decreased current starts to flow and the voltage dropped across the photocell. By detecting this change in voltage, we determined when the light from the elevator buttons changed.
4.1.2.2. Operational Amplifier
This change in voltage was detected by an LM 324 operational amplifier. This LM 324 chip had four individual op amps on it, one op amp for each solenoid driving circuit. This was a standard op amp that any circuitry store carried which was why we chose it. The op amp was a non-inverting op amp connected in a negative feedback configuration with the signal from the photocell connected to the negative terminal, and the output going through a resistor back into the negative terminal. The negative terminal was also connected to ground through a second resistor. By adjusting the values of the resistor, the gain of the op amp was adjusted. The higher the gain the more sensitive to changes light the photocell became. By having the right combination of resistors in the feedback path, the light sensing circuit was used to detect any amount of light. The op amp amplified this change between its two terminals, thus allowing us the needed voltage to light our signal LED. We needed at least 2.7 volts on the terminals of the LED in order for it to turn on. The photocell by itself didn’t provide that needed voltage, but with the op amp it did.
4.1.3. Human Interface Circuit
The Human Interface Circuit consisted of a button switch, an OR gate, and the microprocessor that interpreted the Bluetooth signal. This portion of the system was needed so the non disabled users could still use the elevator as well as those in wheelchairs.
4.1.3.1. The OR gate
The OR gate was a 74LS32 chip that was packaged with four individual OR gates. This cut down on the space required because the OR gates required for all the circuits could be contained in one IC chip. One of the inputs of the OR gate was connected to the microprocessor GPIO output and the other input was connected to the push button switch mounted on the outer face plate. We placed 10k ohm pull down resistors on each of the inputs to keep them from floating to an invalid logic state. Since each input was grounded until a signal came from the microprocessor or the button, the output of the OR gate stayed low. As soon as a signal came from the button or the microprocessor, the output of the OR gate was driven high, and the Solenoid Driver Circuit was activated. This pressed the button on the elevator, and activated the elevator controls.
4.1.4. Microprocessor and Bluetooth Module Circuit 
Figure 17 Archer Main PCBA
This system was integrated on the Archer main PCBA that was implemented to do all the Bluetooth signal processing. It consisted of a microprocessor system with several different attached subsystems (SD, USB, MDOC, RAM, NAND flash, Bluetooth, CF. etc…). This system ran from a Windows Mobile 6.1 operating system. The subsystems that we were concerned with were the Bluetooth and USB subsystems along with a UART GPIO interface that was used to drive the wireless control part of the Human Interface Circuit.
4.1.4.1. Microprocessor
The microprocessor was a Marvell PXA270 that ran at 520 MHz. We used the GPIO’s that were used by the processor for a serial COM interface and modified the connections to drive the inputs of the human interface circuits.
4.1.4.2. Bluetooth Module
The Bluetooth interface used a Socket Mobile BCO4 Class 1 2.4 GHz wireless module that communicated with the microprocessor through a UART interface. This module was used to handle the Bluetooth communication from the mobile device to the host apparatus.
4.1.4.3. USB interface Circuit
We utilized the existing USB client interface of the Archer main PCBA with an Active Sync connection to a PC to download our developed software.
4.1.5. Developed Software
The software was developed in a Visual Studio 2005 environment with a Windows Mobile 6.1 SDK.
4.1.5.1. Bluetooth Pairing
Since the Archer main PCBA ran on a Windows Mobile 6.1 operating system we decided that all the Bluetooth pairing with the mobile device should be handled by the existing Windows wireless manager. This allowed us to utilize the passcode security system that was integrated into the wireless manager. This use of the wireless manager simplified the work on the software portion of the design project. It also presented a useful tool for meeting the security requirements of the project.
4.1.5.2. Host Program
The host program was designed with two different ways of controlling the elevator. The first was a button panel that showed up on the screen of the host device. When it was pushed, it would drive the appropriate GPIO to activate the human interface circuit. The second was through Bluetooth communication. It, like the button panel, drove a GPIO after it received the Bluetooth signal from the Mobile device and interpreted that signal.
4.1.5.3. Mobile Program
The mobile program also had a button panel on the screen that interfaced with the user. When the user pressed a button it would send that signal to the host device for it to process and drive the appropriate circuitry.
4.2. Design criteria
The design criteria that we used mainly came from the force required to press the elevator button. The elevator button was measured to need about ten ounces of force to be activated. The manufacture of the solenoids, Ledex, recommended that a force of one and a half times needed be used in the selection of the correct solenoid. This put us at a needed force of fifteen ounces. For simplicities sake, we rounded up to a needed force of sixteen ounces. This allowed us to have some wiggle room in our design. If we went with the measured ten ounces of force and something changed, we would not be able press the button every single time.
4.3. Discussion of the technical approach
The major portion of the technicalities of this design came in choosing the correct solenoid and the correct MOSFET. The MOSFET, as stated before, needed to be able to withstand high currents and voltages, and be able to work every time.
4.4. Discussion of design details
The details of our project took place over a period of months. During this time we were able to research and test our project. As a resource, we both went to professionals in our fields to get advice on how to design and make our project work. Logan talked with friends and co-workers about the feasibility of using MOSFETS as drivers, and about other questions that he had on the workings of circuitry. Luke talked with coworkers on matters dealing with the use of software and how to program the microprocessors so that they would be able to communicate with each other through Bluetooth. Through the use of our professional friends and our knowledge that we have gained from school and personal experience, we were able to design a project that would accept user input, drive a solenoid to press the elevator button, and then send a signal to the user to let them know which button had been pressed.
4.5. Presentation and discussion of engineering drawings and schematics
The schematics showed the signal flow of the electricity as the circuit was in operation. We had two main schematics. One was for the light sensing circuit, and the other one was for the solenoid driving circuit. This last circuit included connections into the human interface circuitry.
Vout = (1+RF/R)
Figure 18 Light Sensing Circuit
The circuit above shows how the light sensing circuit worked. The light from the elevator button reduced the resistance of the photocell. Then the electricity could flow down to the op amp. The op amp was set up in negative feedback, but in the non-inverting configuration. This op amp amplified the difference between the two terminals and sent out the needed voltage to turn on the LED.
Figure 19 Solenoid Driving Circuit
The Solenoid Driving Circuit was the main portion of the hardware. It was responsible to get the signal from the microprocessor or from the button and push the elevators button. The power needed to drive this circuit came from the use of the lithium ion batteries. The MOSFET acting as a switch, allowed current to flow when it was on and kept the current from flowing when turned off. The Host Program was kept on the main microprocessor. This microprocessor was the brains of the operation. It sent and received the Bluetooth signal. It also interpreted the incoming signal to know which output should be activated to drive the correct solenoid.
4.6. Assembly
The build of the project required us to measure the dimensions of the elevator button panel that we were working with. We also needed to know the position of the elevator buttons to know where to place the solenoids. Once we knew where the solenoids should go, we mounted each of them on the perf board so that they would sit precisely over them to direct the needed force to depress them. The metal cover plate also acts as the mounting frame. It consisted of a piece of 18 gage sheet metal bent in a channel configuration. The top of it was 25cm long and 15cm wide. The channel part of the plate was 6.5cm deep to accommodate the circuitry. The push-button switches were mounted in a straight line down the center of the face plate with the corresponding LED of the circuit placed 5cm to the side of the switch. The perf board was attached to the face plate using six sets of 1.5 inch #6-32 bolts, washers, and nuts. The entire apparatus was adhered to the button panel of the elevator by using industrial strength double-sided tape.
Each circuit was repeated for every button that needed to be pressed. Since we were pressing four individual buttons, we needed four individual circuits. By following the schematics shown in this report, another person would be able to construct a similar project.
4.7. Summary of the final design results
The results of the final design are that the system we designed worked well. All of the components worked together as desired to produce the correct result. The light sensing circuit determined when the elevator’s indicator light came on and displayed a similar light for the user. The solenoid driver circuit drove the solenoid to press the button, and the human interface circuit allowed for the communication of people and the system.
4.8. Performance evaluation
5. Project Implementation, Operation, and Assessment
The system performed just as we expected. The solenoids pressed the elevator button every time, the light sensing circuit worked, allowing for the user to know which floor had been selected, and the human interface circuit allowed for the use of both Bluetooth and manual operation. The system as a whole performed very well, and we expect it to continue to perform correctly for many cycles of operation.
5.1. Details of implementation
In order for us to implement this device fully we needed to mount the device on an elevator. This was done with double-sided foam tape. This double-sided foam tape held our device in place and also it allowed for easy removal after we are finished with the testing and demonstration. We used an Archer PDA that ran Windows Mobile 6.1 Operating System. This allowed for simple operation and control of the Marvel PXA270 Microprocessor. An Archer PDA was used for our testing purposes, but any PDA would work with our program if it were set to run the program.
5.2. Operational test results
Through the use of a prototype we were able to show that our device worked as predicted. We found that the solenoid was not strong enough to press the elevator button by itself, but with the addition of a spring on the push rod, the design functioned. The spring on the push rod pressed the elevator button to the point of activation, but did not activate it. When the signal came, the solenoid activated and finished what the spring started. This allowed the fine tuning of each solenoid driver to the individual elevator button.
5.3. Evaluation of results relative to design criteria
The results of our testing showed that our design worked as we expected it to (with some slight modifications to the plunger.) We also tested out the light sensing circuit. We have shown that the photocell detected the light of the elevator button, and through the circuitry shown in Figure 3, signaled the user that the button was pressed. Overall, we were pleased with the way our design turned out.
5.4. Changes suggested by design results
In our testing of the solenoid driver circuit, we found that the solenoid by itself was not strong enough to press the elevator button. This was because the force of the solenoid decayed in an exponential pattern as the distance increased. Since the distance needed to press the elevator button was greater than we expected, the force that we needed was not there. We decided to add a spring to the push rod. The spring of the push rod started to counteract the spring of the elevator button, meaning that the elevator button had already been depressed slightly. Since the elevator button had already been depressed, the solenoid did not have to travel as far to activate the elevator button. We were then able to obtain the required force to activate the elevator button.
6. Final Scope of Work Statement
6.1. Summary of what has been done
The project was completed in all areas of design and implementation. The system was built and tested and proven to work. Each of the different parts of the system, meaning the sub circuits and subcomponents, were tested individually with successful results.
6.2. Summary of what needs to be done
A final face plate needs to be put on to hide the components from view. The specific button that will be pressed by users, and the external indicator light still need to be mounted to the face plate. The face plate will be made out of sheet metal that matches the rest of the elevator.
6.3. Lessons learned and suggestions for future activities
A suggestion for future activities is to have the operating system of the microprocessor be able to function on any platform. This would require the use of code and a previous knowledge of the intended platform. Another suggestion would be to figure out a way to integrate this research into an existing elevator. This would get rid of the need for an external driver. All that would require is a way to access the computer of the elevator and apply a small piece of code and some hardware that would receive and transmit over a Bluetooth connection.
Another suggestion for future activities would be to see if there was another type of wireless connection that could be used instead of Bluetooth, or how to make it more secure.
6.4. Designer Insights
The solenoids could fall under the category of special details that only we would know. The ratings and the force that they produce can all be found on a data sheet specific to the solenoids, but we are using them in a different way. The solenoid themselves are meant to be a pull type solenoid. We need them to be used as a push type. To accomplish this goal, we have stuck a small finish nail through a hole in the bottom of the solenoid. When the plunger is pulled into the solenoid the nail is pushed out. This makes the solenoid act as a push solenoid, when in reality, it is a pull one. We are also using the force of the elevator buttons as a return spring. As soon as the MOSFET turns off, the force of the elevator button returns the solenoid plunger and nail back to the starting position.
Use of the Archer PCB was unique to our design because of Luke’s employment at Juniper Systems Inc. One of the reasons we selected this controller board was because of Luke’s access to schematics and expert personnel concerning the board. If repeated, this project would most likely not use this same board because the board was designed for other types of applications and needed modification for our design.
6.5. Related project management issues
One issue was that we were not able to start on building the device as soon as we would have liked because of the required amount of paper work. We would finish our paper work project, then turn around and start another one. All of this paper work did not leave much time to build our device.
6.6. System life-cycle issues (marketing, sales, service, retirement)
This project is very marketable to the manufactures of elevators. They do not need to put the actual external face plate on the elevator. All that they would need to do is make the elevator capable of transmitting and receiving Bluetooth data. Then they would need to write a program that would allow the Bluetooth controller to send a command to the main computer.
Once all of the necessary modifications have been made, this idea could be very marketable for the elevator companies. They would have the opportunity to sale this product to the consumer as a new way to help the disabled be more enabled.
The service that would need to be done on this idea would be very minimal, if any at all, if the program was integrated into the elevators main programming. Then any servicing that would need to be done could be accomplished with the routine service of the elevator.
As for the retirement of the integrated program, nothing new would have to happen to the old elevators. Since all of the components would more than likely be built out of lead free devices, the electronics could go to the landfill, or they could be destroyed with the elevator in the same fashion that the elevator is being retired.
7. Other Issues
7.1. Material selection
We chose to use perf board on which to build our circuitry. We have also made a covering out of sheet metal. This allowed for ease in mounting of the project to the elevator and also kept the aesthetics of the elevator the same. The sheet metal covering protects the electronics from being touched. If they were touched, there is a possibility that a shock could occur, compromising the safety of our device. We selected the solenoid because of their capabilities to provide the needed amount of force at a low voltage. They were also cost effective, at just twenty dollars for each solenoid.
7.2. Safety
We took into account the safety of the users when we created the face plate covering. This covering prevented the touching of the electrical components, reducing the risk of electrical shock. Mounting the device with double-sided sticky foam tape eliminated the possibility that the user could get hurt from the accidental detachment from the elevator.
7.3. Reliability
Our design was very reliable. It worked every time, provided that the correct power was provided to the correct portion of the circuitry. When the circuit did not have the correct voltage, our design did not work. If our design had failed, the project board could be taken off of the elevator, and normal operation resume. Another key link in our design was the Bluetooth. If the Bluetooth signal could not be transmitted or received, the wireless portion did not work. Not having the Bluetooth connection did not mean that our device didn’t function. It just didn’t function fully.
7.4. Environmental issues
The components used were marked as being compliant to the standards of the Restriction of the Use of Certain Hazardous Substances or RoHS. This meant that the levels of the restricted materials specified by the RoHS were below the specified standard. These components were safe to use and to handle. They will not harm the environment after they are discarded.
7.5. Impacts of engineering solutions in a global, economic, and societal context
This project impacted disabled people in a very direct way. Our design gave them greater mobility and freedom by increasing their control over the elevator. The fact that this system was operates using a Bluetooth radio signal (or similar radio signal) that can be produced from a wide range of mobile devices makes this system very marketable.
7.6. Maintenance
Our system was relatively low maintenance, but it did require some maintenance on the batteries and IC components. Since the project is battery operated, it was essential to make sure the batteries held the necessary charge. It was also vital to replace the IC components every three months because if they did not work properly, the circuitry failed. Proper maintenance of the batteries and IC components helped ensure a workable product.
7.7. Contracts and other legal and ethical issues
This project did not require the use of any contracts. We did not build or develop this project for any specific company. Luke was given verbal consent by the Director of the Engineering department at Juniper Systems for use of their Archer PDA. These PDA’s provided the micro-processing power of our design. They also provided software support and expertise on the writing of the software code.
There were no legal issues to deal with in the development, implementation, and decommission of this project.
We had considered making our project integrate into the existing elevator. We decided this would cause more trouble than our project was worth if we opened the elevator. This was the only ethical issue that we came across in our design.
7.8. Product documentation
We continuously documented our progress in our lab books as evidence of our procedures. These lab books can be used in a court of law to prove that this was our idea and the work was our own.
7.9. Decommissioning
This project was decommissioned by taking it off of the elevator, cleaning of the elevator to remove the left over residue from the glue, and taking apart the circuitry of the project. As stated before, all of the parts are RoHS compliant, thus they were thrown away.
8. Cost Estimation
8.1. Estimate of system cost (materials and construction)
We estimated it would cost of $300 for the supplies and building materials required for our project. This budget was the correct amount for our project. We spent about $300 on the purchase of supplies. If we were to buy everything from a retail store we would have spent over $1,200. This would have been the price had we paid for the Archer System, which can cost a minimum of $900. Juniper Systems Inc. loaned us an Archer System, free, to use for our senior design project. Thanks to their generosity our out of pocket expense was significantly reduced.
| Raw Materials: | 150.00 |
| Electrical Materials | $100.00 |
| Other Materials (buttons, etc…) | $50.00 |
| Archer Processor | $900.00 |
| Total without the Archer Processor | $300.00 |
| Total with Archer Processor | $1,200.00 |
Figure 20: Budget for Senior Design Project
8.2. Estimate of design cost (man-hours, materials and supplies, travel)
We estimated that we have spent over 500 hours working on this project, which means we spent more than 240 hours a person on this project. These hours included: research and development, talking with professionals to gain insight and opinions, construction, debugging of our code and hard ware, and testing our equipment. These hours also included the time it invested in travel to work on our project and to the stores and other places to acquire the needed supplies. See Figure 7 for our budget table.
9. Project Management Summary
9.1. Tasks: What has been done
All of the required tasks have been done. As seen on our Gantt chart, we were on schedule throughout the semester for being able to finish and present our design on December 8, 2009. These tasks included: finishing our project, testing our project, writing and submitting our final report, and presenting our design to the engineering community at Utah State University. We were able to finalize and present our design on time and on budget.
9.2. Time: Ghant Chart showing activities and their duration and order
Figure 21: Gantt chart of our Time Line
9.3. Facilities
Most of our work was done at the labs provided at Utah State University in the Electrical and Computer Engineering department. These labs included the Analog Lab in front of the ECE Store, the 3rd Floor Computer Lab in the Engineering Building, and other computer labs provided by the ECE depart. We also worked on our project, particularly the software, at Juniper Systems Inc.
10. Conclusion
10.1. Purpose of Report
This report covered our senior design project from the conception through to the completion and dismantling of our project. This report included all of the details needed to reproduce this project. It also described in detail how the radio-controlled elevator system worked, how it was designed, constructed, the results, and how this project affects society. This report was also written to show an understanding of our senior design project, and how the design process proceeded.
10.2. Objectives
Our objective in the research, design, and building process of our senior design project was to help people in wheelchairs operate an elevator easier. This was done through the use of Bluetooth wireless devices and through the use of analog parts to drive the solenoids and signal the end user that the button has been pushed.
10.3. Summary of the final design selection
We selected our parts and components based up on their availability, cost, usability. This meant that we used a solenoid that was not quite ideal. The solenoid that we used was a pull solenoid. We were able to modify it to become a push solenoid. With this pushing action, we were able to activate the elevator button and signal the end user that the elevator was about to move.
10.4. Cost and Timeline
As previously stated, we were able to stick to our estimated cost, and complete the project on time. This was done through the use of a budget to track expenses, and a Gantt chart to show us how well we were following our schedule. We began our project Fall Semester 2008, (August 2008) and finished at the end of Fall Semester 2009 (December 8, 2009).
10.5. Satisfied End Users
We developed a product that we felt would benefit others and lighten the heavy burdens that are often placed upon wheelchair-bound people. Our goal was to create a way to simplify one of their obstacles which was operating an elevator while having to maneuver around a cramped area. Not only were we trying to benefit those in wheelchairs, but also those who make elevators. Our project design was simple enough, but yet, effective that it could be implemented into the regular workings of any elevator and not destroy the integrity of the previous design. We wanted to ensure the end users satisfaction.
11. Appendices
11.1. Engineering design task list
11.1.1. Mechanical design
11.1.1.1. Design outer face plate
11.1.1.2. Design mechanical layout of solenoid switches
11.1.1.3. Build apparatus
11.1.2. Electrical design
11.1.2.1. Design microprocessor system
11.1.2.2. Design radio transceiver system
11.1.2.3. Design solenoid driving circuit
11.1.2.4. Design power management system
11.1.2.5. Layout PCB
11.1.2.6. Manufacture PCB
11.1.2.7. Place components
11.1.3. Software design
11.1.3.1. Design graphic platform
11.1.3.2. Develop driver for radio transceiver
11.1.3.3. Develop operational program
11.1.3.4. Integrate radio interface into program
11.2. Equipment list
11.2.1. Demo PDA to demonstrate operation—fully assembled Archer
11.2.2. Developed device
11.2.3. Several PC’s for documentation development and research
11.2.3.1. USU computers (open access labs)
11.2.3.2. Logan’s laptop
11.2.3.3. Luke’s laptop
11.2.3.4. Luke’s laptop and desktop PC
11.2.4. ECE department test equipment
11.2.4.1. DMMs
11.2.4.2. Desktop Power Supplies
11.2.4.3. Oscilloscopes
11.2.5. Fabrication tools
11.2.5.1. EL 104 room for a place to work
11.2.5.2. Drill with various drill bits
11.2.5.3. Soldering iron with resin core solder
11.2.5.4. Ruler
11.2.5.5. C-clamps
11.2.5.6. Wire cutters
11.2.5.7. Pliers
11.2.5.8. Wire-wrap tool
11.2.5.9. Flashlight
11.2.5.10. Screw driver
11.3. Parts list (part details described above)
11.3.1. 1- Archer Main PCBA (mounted on sheet metal development platform with display, touch-screen, I/O board and keypad)
11.3.2. 1- Custom fabricated piece of sheet metal
11.3.3. 1- 15cmX25cm perf board
11.3.4. 4- pushbutton switches
11.3.5. 4- LED’s
11.3.6. 4 N-type power MOSFETS
11.3.7. 4- Solenoids
11.3.8. 4- Custom Solenoid plungers
11.3.9. 1- pin header jack and 1- pin header plug
11.3.10. 6- 1.5 inch #6-32 bolts
11.3.11. 18- #6-32 hex nuts
11.3.12. 1- 50 watt power resistor 15 ohm
11.3.13. 1- Quad operational amplifier IC with wire-wrap mounting pins
11.3.14. 1- Quad OR gate IC with wire-wrap mounting pins
11.3.15. 10- 1k ohm ¼ watt resistors with wire-wrap mounting pins
11.3.16. 4 10k ohm ¼ watt resistors with wire-wrap mounting pins
11.3.17. 4- 2k ohm ¼ watt resistors with wire-wrap mounting pins
11.3.18. 4- Resistive photocells
11.3.19. 30 AWG solid copper wire-wrapping wire
11.3.20. 20 AWG solid copper wire
11.3.21. 3- 7.4V Lithium Ion battery packs
11.4. Suppliers list
11.4.1. Juniper Systems Inc.
11.4.2. IPACO
11.4.3. ECE store
11.4.4. Radio Shack
11.4.5. Home Depot
No comments:
Post a Comment