Archive for the 'Prototype I' Category

Info Found In Concept Test 1

  • Some residents had trouble efficiently using the touch pad.
  • The residents had a great idea – attaching the touch pad to the chair itself (close to the joystick) instead of on a bracket hooked on the chair.
  • The residents differed on the preferred size of the icons. Some preferred very large icons and others liked the standard sized icons. We did not anticipate this would be the case.
  • Due to stability issues while in motion, some residents explained that the product would only be useful while stationary.
  • The residents all came to the consensus that the pad must be retractable. It cannot always stay in the same spot in front of their view.
  • The residents loved the retractable table. They all saw great value in it.
  • The residents want entertainment built into the pad. Suggestions included things such as television accessibility and the ability to put on light shows. This gave us good feedback because we did not really think of fun add-ons originally. Our main focus was just necessity.
  • The ability of the pad to control a robotic arm was an outstanding idea to the residents. They felt that technology would be a game changer for our product.
  • The residents said the main thing they would use the retractable table for would be eating and drinking.
  • We determined that people with lower spinal cord injuries would probably find the most value in this product.
  • Some of the residents had handle bars on their chair to keep them from falling forward. This is somewhat worrisome because our product could interfere with their ability to properly use the handle bars.
  • The residents who were not in wheelchairs thought the product was a great idea, but they could not really articulate why.
  • We learned that almost all the residents had a very small amount of spending money.
  • Our product could probably not be afforded by individual residents. It would have to be purchased by the facility.
  • The residents thought the speedometer on the screen would be really cool to have, even though their chairs do not go very fast.
  • The residents who already had touch screen phones seemed very comfortable with the product.
  • All of the residents had trouble touching the administrative buttons in the corners of the screen. In order for this to be fully effective those keys would have to modified or removed.

 

Team4 – Prototype I Final Report: Easy Opener/Closer

Introduction:

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.

Description:

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. 

Diagrams:

Reflection:

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

Introduction:

     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.

Description:

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.

https://www.dropbox.com/s/xb4h8mpigx5q2jp/Arduino_code.txt

Diagrams:

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.

 

 

Reflection:

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

Introduction:

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.

Description:

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.

http://www.menards.com/main/home-decor/cabinet-accessories/wall-cabinet-specialty-systems/premiere-pull-down-shelving-system-small/p-1297699.htm

Front view of the manual pull-down shelf.

 

Side view of the manual pull-down shelf.

 

View of the manual pull-down shelf extended.

Reflection:

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

Introduction:

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    

 

Description:

Step 0: Get familiar with Arduino. 

             A. http://www.arduino.cc/ Arduino Website

             B. Guide: http://quarknet.fnal.gov/fnal-uc/quarknet-summer-research/QNET2011/project_files/teacher_files/Getting_Started_with_Arduino.pdf

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

            A. Circui Diagram for 1 motor:http://cratel.wichita.edu/blogs/eecsseniordesignspring2013fall2013/files/2013/02/21.gif

Step 3: Program/Simulate Circuit for 1 motor.

          A. Using  Fritzing.org, Multi-Sim, and Proteus: http://cratel.wichita.edu/blogs/eecsseniordesignspring2013fall2013/files/2013/02/motor_bb.png

          B. Source Code: http://cratel.wichita.edu/blogs/eecsseniordesignspring2013fall2013/files/2013/02/motor_arduino2.ino

          C. Video: http://www.youtube.com/watch?feature=player_embedded&v=K7Hue8Ssdrs

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

        A.  Souce Code: http://cratel.wichita.edu/blogs/eecsseniordesignspring2013fall2013/files/2013/02/motor_arduino_final.ino

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  

http://www.amazon.com/Popular-Mechanics-RC-Tank/dp/B00ATSLYY4

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

             A. Image

             B. .3dxlm Link to files: http://cratel.wichita.edu/blogs/eecsseniordesignspring2013fall2013/files/2013/02/Team7Bot3dxml.zip

             C. CATIA files: http://cratel.wichita.edu/blogs/eecsseniordesignspring2013fall2013/files/2013/03/TeamABotCATIAfiles.zip

Step 5: familiarize with 3D printer.

         A.http://www.makerbot.com/support/thingomatic/documentation/

        B.Guide: http://cratel.wichita.edu/blogs/eecsseniordesignspring2013fall2013/files/2013/03/Thing-O-Matic-Usage-Guide.pdf

Step 6: Weld circuit to board.

            A. http://cratel.wichita.edu/blogs/eecsseniordesignspring2013fall2013/files/2013/02/IMG_0111.jpg

Step 7: Wire arduino to board.

          A.

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. 

                           http://cratel.wichita.edu/blogs/eecsseniordesignspring2013fall2013/files/2013/02/2013-02-27-20.37.581.jpg

                           http://cratel.wichita.edu/blogs/eecsseniordesignspring2013fall2013/files/2013/02/2013-02-27-20.37444444444441.jpg

Diagrams:

Refer to Step 6/7.

Reflection:

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.

                                                     XBee: http://www.adafruit.com/products/128?gclid=CNyA95zT2bUCFQLhQgodVgUA2w

                                                     GumStick: https://www.gumstix.com/

   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

Introduction:

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)

Description:

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:

Diagrams shown in description.

Reflection:

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

Introduction:

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

Description:

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.

Diagrams:

 

Reflection:

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

Introduction:

     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.

Description:

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.

Diagrams:

Robotic Plot Table Camera image for Prototype I write up

Initial plan of the project

Reflection:

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.

[[Team 4] – Progress Report III for Prototype I: [Easy Opener/Closer]

Goals for the week:

Work on initial design on jar opener, and figure out how to retrofit our current model to work, implement a relay to allow the motor to rotate both ways. 

Meeting times/dates

Tuesday-7:25-8pm

Thursday 3:30-5pm

 

What we did:

On tuesday Zubair and Michael met with the teacher and discussed some options. Nick was unable to attend due to the weather. Started thinking about design and materials that could be used. On Thursday there was a slight setback with one of the diodes on the bridge rectifier getting blown up. Nick worked on removing the bad diode and soldering a new one onto the bread board. Michael and Zubair worked on how to implement the new design to be able to work on the old frame.  Over the weekend Michael found another easy jar opener for much less than the initial one purchased and he bought it. Hoping to be able to use the motor or some of the parts from it. 

What we didn’t do:

Set up a relay to allow the motor to spin both ways, with the flip of a switch. 

Completely figure out our design. 

Where we are stuck:

Trying to figure out how our new model will work and differ from the original, stuck on figuring out the mechanical properties

Team 3! – Progress Report III for Prototype I: Mechanical camera stand control system for wheelchairs

Goals for the week:

-Kusay will bring a tripod on this thursday meeting. We will work on that.
-We will build styrofoam model for the whole mechanical design with the dimensions and check it and then start cutting the aluminum sheets after that.
-We will have to figure out where to get the aluminum sheets from…

Meeting times/dates

Same as in code of conduct: Tuesday and Thursday 6 pm wallace hall

Individual Hours:

Bill will work on catia design

Kusay will work on tripod

Rupak and Saeed will look for parts for the design

What we did:

Tuesday:

-Tested two servos and a motor with arduino uno hooked up with 2-axis joystick for pan and pitch and one-axis joystick for up and down(Motor).
-up and down movement on the stick will cause the motor to reverse its direction for up and down movement.
-Built a styrofoam sample model for the pitch movement to visualize the idea.
-We have solenoid to be used for locking the vertical shaft

Thurday:

-Got some parts from hardware store and assembled the design for pitch movement.

-Base for the camera is been mounted on turntable. Camera will rest on hinge which will allow the pitch movement.

-Drilled holes and screwed hinge, camera support onto the rotating platform of turntable.

-Drilled a wooden base and screwed it with the bottom of the turntable (Fixed platform)

 

What we didn’t do:

-We didn’t built the servo arm for pitch and pan movement.

-Other mechanical design is still left including vertical shaft movement and the integration of control with the design

Where we are stuck:

-Tripod that we got is heavy and would not fit with our design. We have to look for a lighter tripod to extract the vertical shaft for our design.

-We have not came out with a solution for connecting servo to the camera base.

-We are thinking to cut glass in the lab for mechanism to control pitch and pan

Notes/Misc: