Archive for the 'Final Report' Category
Team4 – Prototype I Final Report: Easy Opener/Closer


We are trying to build a machine that uncaps and re caps the bottles/jars lid.  We figured out the part where we can reverse the current so that motor can spin both ways and cause the plate to both un-cap and re-cap the bottles. A couple of residents at CPRF wanted a device that can uncap a bottle since they do not have mobility in their hands or it is difficult for them to do it with their hands. Although their are similar products in market that can do that thing so we ordered on of the device and tested it for success rate. To our disappointment the device can only uncap and is not very helpful. So based on this idea we went on and stick to this project so our efforts and skills can help them with this trouble they are facing.We used the motor from the similar device and designed our own plate which rotates and uncap and re cap the bottle.


So far we have build as per we talked in our meetings. We have built a strong base for the motor and connected a switch to it so the motor can rotate the plate both ways. We are struggling with connecting that to AC power supply because unfortunately we burnt it, fixed and re burnt it. We might be needing Tom’s help in this part but he suggested we can use a DC power source. After building the base we made a plate that sticks to the base and which can rotate to help the bottles uncap. This is what so far we planned on doing before the second meeting at CPRF so we can show the residents that we are working on their idea which will definitely going to help them in the long run. Although our idea is based on a thing that has already been in market but we differentiate our product in technicality of doing a better work as well as using a different approach to sort out this problem. The hardest part is still to come which is mounting a clipper that can hold the cap so the plate rotates and do its work as well as incorporating sensors to measure pressure. There are several pictures that is added along with it that can help you get the idea better on our progress. 



I think everything we have decided on up till now pretty much worked. Instead of having the clipper rotate and uncaps the device we do it differently by pressing on a cap and rotating the plate instead. We still have to decide on how to mount that on top of it but eventually we will figure out a way. If we were to expand this project we will have to incorporate more sensors on the device and have it work for all the type of caps as well as water bottles which are very thin and have a very small base.  

Although this is an online submission, please use language and formatting appropriate for a final report (capitalization, well-constructed sentence structure, paragraphs, etc.). Also please delete text such as this which is clearly to help you and not intended as part of the report. You may change the form of this template as you wish, but please include the main elements outlined.

3! – Prototype I Final Report: Mechanical camera stand control system for wheelchairs


     Our project is to build a mechanical camera control system for the wheelchair clients. The
outcome of this project will have a camera platform mounted on wheelchair. Physically
challenged people will get an easy and effective way to control the position of the camera
using joystick. The biggest difficulty that wheelchair users might have is to properly position
the camera by holding it in their hand. Some people have difficulty in holding the weight and
aligning the camera. Despite of their hard effort in using camera, the shot that they take may not result as desired.

      Our mechanical design will hold the camera so people can position it and use the
interface of the camera for the desired result. We believe that our project will help
handicapped people to explore the world with their own perspective and share it with others.
Furthermore, it will also empower the handicapped users who are interested in photography to
even take it as a professional career. Our prototype I is a step closer to our final project. In this
prototype I, We have been successful to control the angle of the camera.


As a team we started discussing the idea of building an electro-mechanic tripod/camera stand for wheelchair after our visit to CPRF. The idea came when one of the residents of CPRF descried her difficulty in using her professional camera.

The initial ideas about our design is given below:

  • Joystick which could be mounted on the wheelchair so we need a clip attached on the joystick.
  • Vertical stand for the camera which is mounted on the wheelchair. This stand can go up and down. Top of this vertical shaft is connected to the fixed platform.
  • The base of the camera has a hinge for controlling pitch angle and is mounted on the rotating platform. There will be a fixed platform underneath the rotating platform.
  • Use three servos to control the position of the camera mounted as shown in the picture.
  • Joystick and servos will be connected to Arduino board so that they can communicate with each other.

We started by cutting the rotating platform from a piece of wood. Then, we used L-shaped metal from hardware store and connected it to hinge that can easily move the camera (pitch +/- 45 Degrees). After that we used a turntable (lazy Susan) in between the rotating platform and the fixed platform. Later we mounted the servos, one on rotating platform for the pitch movement and the other on fixed platform for pan movement.

Parts used for prototype I :

  •   Door hinge
  •   Wood, metal and dense plastic
  •   Two servos
  •   Arduino
  •   Turntable (4×4)
  •   Joysticks

The arduino uno code that we have used can be found in the link below. This code also includes the control of motor for the up-down movement which is not used in this prototype.


Two sketches above are the design that we have been following from the initial prototype I. Below are CATIA drawings of the top part of our design.




For the prototype I, we have managed to control the pan and pitch movement of camera using joystick control system. We have learned a lot in this prototype and now we know the way ahead and how we are going to tackle it. We believe that we have spent too much time for the mechanical design and getting stuck in a certain idea. Our plan for the second prototype is to use gears for the pitch and pan movement and also allow the pan to move 360 degrees. We will focus more on electronic section of the project to improvise the control system and make it easier and effective for the users to control the camera. We were unable to complete the up down movement of the design which has been challenging to us. We are ready to face the problems that we have encountered so far and complete the project that we have been working on.

BitShifters – Prototype I Final Report: Shelf Assist


When people are confined to a wheelchair, they suffer from not being able to reach high cabinets and shelves. Manual pull-down shelves already exist, but people confined to a wheelchair would still not be able to reach these shelves in high cabinets. This project would solve that issue by supplying a high cabinet with an automated lowering shelf. The wheelchair occupant would be able to automatically lower the shelf via a remote control (probably located underneath the counter) to an appropriate height.

The first prototype is just the manual pull-down shelf that will eventually be motorized and controlled by remote.


Originally, the shelf was to be built from scratch, which would be mostly mechanical work rather than electrical and computer. In order to bypass the mechanical aspect, a manual pull-down shelf was purchased from Menards.

Front view of the manual pull-down shelf.


Side view of the manual pull-down shelf.


View of the manual pull-down shelf extended.


For our first prototype, we initially planned to build the shelf ourselves. We looked at wheelchair lifts at the CPRF and planned to model the mechanical part of our shelf from that design. However, to much time was being spent trying to come with the mechanical design, so we decided we would modify the pre-assembled shelf. Because so much time was spent trying to come up with the mechanical design, we didn’t have time to attach the motor to the shelf like we wanted. But since we have a pre-assembled shelf, we can move on to applying electrical components. We would like to include a wireless remote control (probably Blu-tooth or RF). Also, we plan to add sensors on the bottom that would stop the shelf if something was in its path. We should also consider electric company codes: each 20 amp kitchen breaker can only have two outlets (9 amp max). So, we’ll have to use a motor that consumes less than 9 amps.


The A Team – Prototype I Final Report: Micro Cyber Watch Dog


The objective of this project is to create a wireless micro robot, that will have the ability to aid law enforcement, private organizations or other public safety organizations by giving them the ability to access unknown locations or enclosed areas where there are unkown dangers.  The micro robot will also give them the ability to access places not accessable by other means.  It will also have the ability to surveillance the area (record/transmit video), and provide, or produce audio.

In this prototype we have so far, made a small wired robot that can move in two directions using the arduino uno, two pre-existing RC robots, and a motor driver. One robot was used for testing and the other for implementation. We hacked both RC robots and wired the Arduino uno to control the motors.

We chose to hack pre-existing robots instead of building one from zero because of the time that will take to build one from zero and the deadline for prototype I.

Parts Used:

qty item with link unit cost comments
1 Arduino micro-controller    
2 Prebuilt RC robots    
1 Motor Driver L293D    
 XX Bunch of Wires    
 4 Switches    
 1  Unsolder/Solder Breadboard    
 4  resistors    
2  capacitors(optional)    
 1  9V AC adaptor for Arduino    
 1  9V battery    



Step 0: Get familiar with Arduino. 

             A. Arduino Website

             B. Guide:

Step 1. Design Circuit that will control two motors using Arduino One.

            A. Circui Diagram for 1 motor:

Step 3: Program/Simulate Circuit for 1 motor.

          A. Using, Multi-Sim, and Proteus:

          B. Source Code:

          C. Video:

Step 2. We built the circuit/Simulate that will control two motors using Arduino One.

        A.  Souce Code:

Step 3. Order two RC robots, one hacked(smaller one) and the other was built from zero(bigger robot).

       A. Smaller Robot

      B. Bigger Robot

Step 4: First chasis was created based off the bigger robot to potentially be customized later.

             A. Image

             B. .3dxlm Link to files:

             C. CATIA files:

Step 5: familiarize with 3D printer.



Step 6: Weld circuit to board.


Step 7: Wire arduino to board.


Step 8: Addional Help

         A. Senior Analyst from NetApp, Ivan Quiroz, contact him for additional help and research.

        B.  Notes: The more the stuff inside the robot, the bigger the robot and the more power (battery power) it requires. If using Arduino, we have to pay attention to the timers. If using raspberry pi, we might loose the term micro because of the size of the chip. Ivan demonstrate how to use an H-                          bridge. 




Refer to Step 6/7.


We were able to program/design a robot that will move in two directions.  Given the size of the batteries, will determined the size/weight/fuctions of the robot.

In the future, we are planning on:

      A. Make it wireless:  Deciding  between using the XBee which will give us limited functionality but less power consumption and the GumStick module(computer onboard) that will give us more flexibility but more power consumption.



   B. Add video camera

   C. GPS/temperature sensors 

   D. New ideas/issues from potential client ( Kyle Garwood, Sergeant):
                 1. It would be handy to fit on an officers tool belt.
                 2. It would be useful if it projectile capabilities (e.g. gas, explosives, ammunition)
                 3. SWAT and surveillance operations
                 4. Portable
                 5. Discrete
                 6. Cheap

         Potential Issues with micro bot:
                 1. Search warrants needed.
                 2. Concerns about radio frequency interfering with other channels
                 3. Interception of radio frequency
                 4. Battery life.
                 5. Privacy concerns.

Although this is an online submission, please use language and formatting appropriate for a final report (capitalization, well-constructed sentence structure, paragraphs, etc.). Also please delete text such as this which is clearly to help you and not intended as part of the report. You may change the form of this template as you wish, but please include the main elements outlined.

Blue Team – Prototype I Final Report: Smart Cushion


The Smart Cushion was conceived specifically to reduce instances of pressure sores in wheelchair-bound individuals. Pressure sores are caused by a force (such as a person’s body weight) being applied consistently to an area of soft tissue, thereby obstructing blood flow and causing tissue failure. Because a great many wheelchair users have limited mobility, as well as limited sensation, it can be difficult for them to change position with sufficient frequency.

To combat the difficulty many wheelchair users have in staving off pressure sores resulting from long periods of sustained sitting, The Smart Cushion will comprise a 2D array of air cells that will respond to variations in the user’s positioning by equalizing pressure across the contact area. Each cell will be equipped with a small pressure sensor, which in turn will be monitored by an Arduino microcontroller to ensure that each cell’s pressure stays in the target range. A small compressor motor will handle inflation duties.

For the first prototype, we chose to focus on a three-way interface between the Arduino microcontroller, a pair of Freescale Semiconductor pressure sensors (rated at 14.5 psi), and a pair of small inflatable pillows. The primary objective was simply to demonstrate that the Arduino could poll multiple sensors and get varying pressure values in real time. Furthermore, we chose to interface the Arduino with the Processing multimedia programming environment in order that we might display the retrieved data on a laptop.

Parts List

  1. Arduino Uno microcontroller (1)
  2. Freescale Semiconductor MPXV5100GC7U pressure sensor (2)
  3. Intex camping pillow (2)
  4. 1/2″” Inner Diameter Vinyl tubing ~ 2ft
  5. .18″ Inner Diameter Vinyl Tubing ~5ft
  6. Small Circuit Board
  7. Several Circuit Wire Connectors
  8. 1/2″ to 1/2″ Inner Diameter Connector (2)
  9. .18″ to 1/2″ Inner Diameter Connector (2)


Several days were spent before construction getting used to the Arduino and Processing coding environments.  We wrote some code that could take two potentiometers as inputs and output their values.  We slightly adjusted that code to work with our sensors and then found a conversion factor that could change the sensor’s output to psi. 

(Our trial run of our two sensor set up)

The first thing we did to set up the project was drill out the safety in the air cushion (the part that requires you to squeeze the air nozzle in order to blow it up) so that the air flow would be unobstructed.  We then connected our 1/2″ to 1/2″ Connector to the cushion, which fit rather nicely, and then the other end of the connector went to the 1/2″ ID Vinyl tubing.  A small clamp was applied onto this portion of tubing as the connection was not completely sealed.

The next part was to connect the smaller tubing to the pressure sensor.  We used a small slit of electrical tape around the sensor to hold the tubing in place and then fit the tubing over.  We also wrapped a small cable tie around it to ensure the the tubing was secure.  After that tubing was on the smaller tubing could connect to the .18″ to 1/2″ connector to complete the tube.

Next we soldered our sensors onto a circuit board in order to make the project more presentable.  The sensors give us a reasonable output and this first prototype is complete.


Diagrams shown in description.


On the whole, things went as expected with our first prototype. For the most part, we managed to meet our primary goals each week. In doing so, we put ourselves in a position to succeed by avoiding any tendency toward deferring difficult tasks. We faced some minor (primarily aesthetic) issues with code output, but our primary objectives, such as interfacing Arduino with the Processing programming environment, were implemented with relative ease. The sensors we chose seem to be a good fit for the project, although there exists some uncertainty regarding whether or not the pressure rating we chose will be the best fit going forward.

Although most everything went smoothly, we still have reservations about some minor details, and there are certainly things that could have been done differently. Despite being happy with our choice of sensor, we aren’t entirely sure that our conversion into psi is as accurate as it can possibly be. The sensor data sheet shows a linear relationship between output voltage and pressure, but the graph was not as detailed as we would have liked, and we’re skeptical that correlating maximum voltage output and maximum pressure rating was the most accurate way to come up with a conversion factor for our code.

Another area where we’d like to have a “do-over” is in the procuring of materials. We made several trips to some of the big-box hardware stores before realizing that going to a smaller specialty store is usually more beneficial. Even still, our application unfortunately required a special order. Even though our item arrived on time, we cut it very close. Had we made some of those materials decisions earlier, and gone to the specialty store to begin with, we would have saved ourselves some unnecessary stress.

Having built our first prototype, we feel that we’re on the right track. Although it is still early in the project life cycle, we’ve been given no reason to believe that we can’t successfully implement The Smart Cushion as we originally imagined. As we expand our project into the second prototype, we will be given further insight into our project’s feasibility as we begin to implement a mechanism for inflating/deflating individual air cells.

Eh Team – Prototype I Final Report: Universal Wheelchair System


One of the major problems we noticed early on after we spoke with CPRF residents and other senior design groups was that there was not a central device to run all functionalities of the electric powered wheelchair.  Many groups in the past had created functionalities that could be added to the wheelchair to try to improve the quality of life for the residents; however, each of these functionalities ran on its own interface, and had its own display.

Therefore, our idea was to create open-source interface that could be used for all projects.  The interface we have designed currently runs as an app on an Android based Coby tablet.  The app currently displays four tiles, with each tile having the capability to run its own functionality or display data from other devices (i.e. wheelchair speed, battery life, power, etc…).

Parts Used for Prototype 1:

Coby 7″ Kyros Tablet (Running Android 4.0)

Arduino Uno

GMYLE Adjustable Swing Arm Tab


Our first step was to select an appropriate tablet to run our interface on.  We selected a Coby Kyros” tablet because of its affordability and because it ran Android 4.0. Also, the Kyros did not charge using its micro USB port, allowing us to use the USB port for communication with the Arduino or future functionalities.  The one problem we did run it to with this tablet, however, was that we had to root the tablet to run Google Play to be able to upload our app onto it.

Next, we selected a swing arm to attach the tablet to the wheelchair, as we wanted the tablet to be able to be attached permanently to the wheelchair, but also so that it could be moved out of the way if the resident needed room.  We decided to use the GMYLE Adjustable swing arm because it had two axis of rotation, it had a way to attach it to the wheelchair, and we believed it was large enough to hold our Coby Tablet.

We tried to use our app to communicate with an Arduino Uno to run a retractable table created by a previous design group.  However, we found out that we need an extra cable to be able to communicate between the Arduino and our app.  We have since ordered the cable, but we have not received it yet.

What we have created so far is an app that we can run in an emulator.  The app code can be found at our GitHub, which can be found for the Android App here and  for Arduino here.  The app opens to show four tiles.  Each of these tiles can be used to run their own functionality  which will be connected later.  We had originally planned on one of these tiles controlling the Arduino connected to the retractable table for prototype one; however we were unsuccessful.  As we continue to develop our project, we hope to tailor each of these tiles to run fuctionalities, possibly including those created by previous electrical engineering senior design groups.  Also, because this system will be an open interface, any future group wanting to add functionality to the wheelchair should be able to use our system to expedite the process.




Looking back on our project, we probably should have started out trying to use the soft modem for communication between the app and functionalities, as it would have simplified the code.  Also, we could have saved ourselves a lot of work if we had ordered a different tablet, one that would have run Google Play or would have been recognized by Eclipse so that we could have uploaded the app directly to the tablet.  Our app runs correctly in the emulator, but we have not been able to test it on the tablet yet.  Also, in our next prototype we hope to be able to successfully communicate between the Arduino and the app.


Although this is an online submission, please use language and formatting appropriate for a final report (capitalization, well-constructed sentence structure, paragraphs, etc.). Also please delete text such as this which is clearly to help you and not intended as part of the report. You may change the form of this template as you wish, but please include the main elements outlined.

Deliberate Gecko – Prototype I Final Report: RPTC


     When we went to the Cerebral Palsy Research Foundation, one of the problems we found was that there was an employment opportunity that was inaccessible to wheelchair users. The current job is to bend over a table with a microscope and take precise measurements of a print at various locations on the calibrated plot table. The measurements are precise to 1/1000 of an inch. The current problems that are the focus of the project include back strain, eye relief, eye fatigue and wheelchair inaccessibility. 

     Deliberate Gecko is developing Project RPTC for the purpose of increasing the ease of taking precision measurements from a calibrated plot table. The aim of the project is to mechanize the measuring process, eliminating the current cause of back strain, eye fatigue and wheelchair inaccessibility, as well as the need for eye relief. From our implementation, this should also increase productivity from being able to take the same precision measurements much faster.

     For Prototype I, we have made a box that can move on metal rails in two dimensions. The box will hold a camera or microscope as well as motors for movement. The box glides on a rail system made from square aluminum tubing for the Y-axis and rolls on a frame made from rigid conduit for the X-axis. The rigid conduit is connected on the ends by type LB rigid conduit bodies. The box is moved using pulleys, string and stepper motors.

This prototype has been built from the following parts:

  • 3/4″ rigid conduit – 30′
  • Type LB rigid conduit body – 4 units
  • Rigid conduit compression connector – 2 units
  • Aluminum box
  • Square aluminum tubing – 12′
  • Angled aluminum – 2′
  • Stepper motor
  • String – 110″
  • Small pulley – 4 units
  • Caster wheels – 8 units
  • Nylon bushings – 8 units
  • Nuts, bolts, washers – 1 handful (24 bolts, 24 nuts, 4 washers)

Prototype I has the ability to travel along the Y-axis smoothly. The frame for X-axis movement has been built, but the motor has not yet been connected.


We built a rectangular frame out of rigid conduit, Type LB conduit bodies and compression connectors. Steel parts purchased at Lowes.

We drilled holes into an aluminum box to mount it on a gliding system on rails for the Y-axis, then also mounted a motor to the box. Aluminum parts purchased at The Yard, motor found in lab.


We took apart some caster wheel assemblies to get the wheels, which we mounted on some angled aluminum. That was then mounted on the Y-axis rails. Pulleys were attached to the top of the rails, strung with .023″ steel cable.

The box initially required a force of over 2 lbs to move. We sanded and applied steel wool to smooth the square aluminum, lowering friction even more. We were able to reduce the force required to approximately .33 pounds.


Robotic Plot Table Camera image for Prototype I write up

Initial plan of the project


Making purchases at The Yard was a very good decision. It would have been better to have gone there first instead of Lowes. Using furniture glides on the square aluminum for the Y-axis was also a good idea. Along with the polishing of the rails, it was a cheap way to decrease friction and noise of Y-axis movement. In the initial design, we chose to use concave wheels on the X-axis for movement, this ended up being too complicated. Using 2 wheels at an angle was a better plan because it was much simpler and achieved the same purpose. A change that could have been made to our design is to mount the motors on the frame instead of in the box. This would have lightened the weight of the box and have the motors not moving themselves with the box.

Currently, the best way to solve our initial problem of taking measurements without needing to lean over a table would be to utilize a large precision scanner. The problem with this method is that the scanner would be absurdly priced relative to our project, greatly outweighing the benefit provided.

More improvements to this project could be made, including an absolute or relative positioning measurement system, to entirely eliminate the need of the expensive calibrated plot table that the current project is mounted to. This would require more fine tuning and customized parts that are outside of our current goals and budget. The prototype we have constructed so far could be built upon and eventually reach this level.