Archive for the 'Initial Writeups' Category
Initial Writeup Assignment

Write an initial writeup for your prototypes.

  • due midnight before October 30

Find all the details in the template for the assignment

[Three Musketteers] – Prototype II: [Wheelchair Lasertag]

 

Description of Idea:

The idea is to create a system That allows the residents to play a movement based game similar to laser tag. Using GPS and a digital compass we track their localized movements and position vector. That information is used when the player wants to ‘fire’ upon another player. All the information is tracked by a central server via WiFi.

Description of Prototype:

Prototype II will take the data collected by prototype I and send it via WiFi to another computer. That computer will then access it to observe the sensor package. We got very lucky with Prototype I to be able to add the GPS without much difficulty. So prototype II just needs the WiFi.

Timeline:

 

date process and goals comments
Nov 6
  • all components are in. Start initial playing with components, figuring out how they work.
  • continue experimental programming learning to use Arduino microcontroller
  • complete interviews with target consumers/consumer groups
 
Nov 13
  • initial Arduino programming complete
  • skeletal structure complete
 
Nov 20
  • hardware and software working together, although perhaps not robust yet
 
Dec 8
  • prototype completed, working, report submitted
 

Materials Needed:

If you are needing EECS to provide materials for you, list them here. We can then work out how to obtain these with our reimbursement policy:

qty item with link unit cost comments
1

WiFly Shield

$69.95  
1 arduino uno 30 any Arduino OK, including older Arduinos
1

Compass Module – HMC6352

34.95  
1 Resistor assortment 7.21 we don’t need this many resistors, but we don’t know what we need yet. Isn’t there a pile of ‘em somewhere we can experiment with?
       
       
       
       
       
       
Lucky 13 – Prototype II: Battery Assisted Grabber

Description of Idea:

Our team is looking to build a motorized grabber for anyone who has a limited reach. It will be designed to telescope out, grab an object, telescope back in, and release it using buttons at the handle. 

Description of Prototype:

We have several directions we wish to expand on for this prototype. First we’re looking to prepare the design for telescoping, so we’re aiming to cut down the shaft and build this next prototype 1/3 the length and in such a fashion as to allow the design to be mounted to to more segments of shaft that will telescope the entire design out. Our first prototype doesn’t quite meet the design needs for that as of yet. This will also involve a significant shortening of the linear actuator which should result in a smoother opening and closing of the arm.

Second, seeing as the entire Prototype is meant to attach to two more lengths of shaft eventually we’re looking to cut down weight as much as possible. The aim is to build it out of lighter weight material (plactic pvc instead of aluminum and electrical conduit tubing). We’re also exploring other smaller motors that we could substitute for our current dc motor. It’s a little to large and heavy to incorporate comfortably into our design.

Lastly we’re also going to take this next prototype as our chance to start working on sensors we can use to monitor when our grabber has grabbed something. This will allow a user to simply tap a button and the grabber will close around the object on it’s own and stop when it has a hold of it. We’re currently exploring to sensors for this need. The first is a pressure sensor that will stop the arm from closing once it has applied a set amount of force on an object. The second is a load sensor that we would hook up to the motor to monitor how much current it is drawing and by extension how much resistance the arm is meeting. We feel both have merits and aim to determine which is better suited for the job.

If we have time we’ll attempt to pursue our ideas for telescoping but that will most likely be pushed back to next semester. In order to fully realize our design we need to implement telescoping and look into a wheelchair mount. But we feel these can be handled easily enough in the time allotted next semester.

Timeline:

The below table is just an example for how you might do a timeline. Content in the table is also just example content. Feel free to change and restructure the below table as you wish:

date process and goals comments
Nov 6
  • Begin fatrication of new grabber prototype (cut down grabber utilizing a smaller linear actuator).
  • Pick out a new smaller motor for our 2nd build.
 
Nov 13
  • Work with new sensors (force and load) on the arduino.
  • Continue fabrication of new grabber.
 
Nov 20
  • Control motor with one or both sensors and decide on which to proceed with.
  • Wrap up fabrication of grabber.
 
Dec 8
  • Put finishing touches on prototype (touch up interface, install arduino into grabber, mount all sensors).
 

Materials Needed:

qty item with link unit cost comments
8 DC Gearhead Motor $12 Smaller lighter motor that still delivers acceptable amount of torque and speed.
1 Force Sensor $10-15 A simple sensor to measure the amount of pressure the grabber claw is putting on an object.
1 Load Sensor $10-15 A simple sensor to gauge the amount of current being used by the motor to determine the pressure it is applying on an object.
1 PVC piping $5 Lighter weight material to be used for the shaft of our new grabber.
       
       
       
       
       
       
Team 9 – Prototype II: Remote Piano Pedal

 

Description of Idea:

The remote piano pedal is designed to enable people who are unable to use their legs to operate the pedals of a piano.  This action is accommodated by attaching a motion sensor to any moving part of their body. Based on this movement, the motion sensor will send a signal to the Arduino /microprocessor which will in turn signal the motor to rotate. The motor will rotate a Cam that will operate the pedal of the piano causing it to move either up or down as desired.

 

Description of Prototype:

Prototype one was tested by the use of two potentiometers. One potentiometer represented the user interface. In prototype two, this potentiometer will be replaced by a movement sensor. The second potentiometer was attached to the shaft of the motor. When adjustments were made to the user interface, the potentiometer sent a signal to the arduino. This signal was interpreted as a value between 0 and 1123. This value was compared with the value of the potentiometer connected to the motor shaft. If the interface value was lower that the motor value, the motor was prompted to rotate backward. The movement of the motor adjusted the second potentiometer downward until the two numbers matched. At this point the motor stopped and waited for another signal. Likewise, when the interface value was higher than the motor value, the motor was driven forward changing the value of the potentiometer until the values agreed.  In this way, the position of the motor was tracked and the tendency of the position of the motor to drift was avoided. This aspect of the first prototype worked well and prototype two will move toward a permanent mounting bracket and gear drive. Three possible designs (Figure 1) have been considered which revealed areas for design improvement. The current design (Figure 2) is much like design three but with the potentiometer moved down to the side of the motor. Prototype two will explore cam design and implementation.

     The motor will be permanently mounted in as a unit. This unit will be adjustable by a foot screw that will set the height of the cam. There will be a ballast that will connect the unit to the bottom of the piano.

     An infrared distance measuring sensor unit is being used to provide an input signal. These values range from 0 to 590 and are scaled to match the motor’s potentiometer values. The input values are buffered by a capacitor installed at the output.

     The interface between the user input and the motor is the Arduino microprocessor which is loaded with a computer program that executes the logic. A motor shield is used as the Arduino only supplies 5 volts and 12 volts are required to run the motor, additionally, the polarity of the motor inputs must be reversed in order to drive the motor in both directions. This was accomplished by the use of the H-bridge motor shield.  A wiring diagram is included below.

     Prototype two should be able to move smoothly in response to an external input.

The motor should provide sufficient torque and speed to operate the pedals effectively.

The unit design should allow for future upgrades such as wireless operation.

The unit should have an aesthetic appeal.

The unit should be user-adjustable in order to work on a variety of pianos. (or sewing machines, and other devices)

The unit will measure approximately 6”h x 4”w x 5”l

Anticipated cost for the first model excluding research and development is around $400. Production of several more would bring the costs down substantially.

 

Timeline:

The below table is just an example for how you might do a timeline. Content in the table is also just example content. Feel free to change and restructure the below table as you wish:

date

process and goals

comments

Nov 6

  • Fabricate a mounting bracket
  • With pieces secured, continuous improvement of the Arduino programming to insure smooth and reliable operation.
  • complete interviews with target consumers/consumer groups

 

Nov 13

  • initial Arduino programming complete
  • skeletal structure complete
  • cam installed

 

Nov 20

  • hardware and software working together, although perhaps not robust yet

 

Dec 8

  • prototype completed, working, report submitted

 

 

Materials Needed:     

qty

item with link

unit cost

comments

1

12 VDC motor

130.00

Available in the lab (at least for prototyping)

1

arduino uno

30

Available in the lab

1

Cam

N/A

 

1

Capacitor assortment

7.21

A capacitor is needed to smooth out the signal input.

1

Metal Bracket

N/A

 

 

 

 

 

 

 

 

 

On The Fly – Prototype II: Home Automation Framework

Description of Idea:

Our intent is to develop a web application that can remotely control the electronic devices in one’s home via mobile interfaces such as smartphones & tablets, or any OS with a web browser. The underlying technology will likely utilize an Arduino and a small, low-powered web server such as the Raspberry Pi.

Example systems that we may monitor or control:

  • Technology & Entertainment:
    • TVs
    • Radio/CD/MP3 Player
    • Computer
  • Energy-Saving:
    • Lights
    • Ceiling fans
    • Thermostats
  • Appliances
    • Washing machines
    • Stoves
    • Refrigerators
  • Security Tools & Devices
    • Security cameras
    • Electric door latches
    • Electric window blinds


Goal: Facilitate ease of access & control of electronic devices for those who are busy, have a disability, or are not physically present in the location of the device.

Description of Prototype:

Prototype II will be an extension of Prototype I in that we will continue to control devices remotely, but we will implement our own version of the actuators/remote/wall outlets/controls. Instead of using the Stanley commercial ones, we plan on building our own, so as to eventually reduce costs and avoid using commercial products in our project design. This will also allow us to expand on the functions of the actuator, potentially implementing such things as dimmer lights, fan power setting control, locks, and vertical blinds operation.

While the focus of this Prototype is to make our own working actuators, we do not expect to be able to finish all the modules that we would like to launch the product with. Therefore, in future prototypes and in the final design, we plan to continue expanding our range of available modules. We may also work on aspects of program and hardware specifications that build security (e.g., passwords) into the device, account for potential issues like overlapping radio frequency use in adjacent houses, and optimize code. In contrast to Prototype I, Prototype II uses its own wireless actuators, so it’d be easier to build different modules.

We anticipate the cost of Prototype II to be slightly more than Prototype I, due to using our own custom, more powerful/flexible components for the actuators rather than the Stanley commercial product. Each module will cost approximately $15:

  • $5 RF receiver
  • $3 ATTiny
  • $3 case
  • $2 Relay
  • $2 Power Supply/conversion from AC


The server module will also cost slightly more:

  • Raspberry Pi – $35
  • Case (3D printed for prototype) – ~$5
  • High-power RF transmitter – ~$25
  • Power Supply – $2
  • Ethernet Cable – $2


Things Prototype II should be able to accomplish:

  1. Communicate messages from the server to a wireless actuator.
  2. Be able to act on the message in a variety of ways, programmed specifically for the module.
  3. Be able to receive data from actuators, such as state of a light, lock, or fan.
  4. Have an updated web interface that allows for the different options of power control, fan settings, or dimmer, depending on the module controlled.
  5. Be able to act on either a timer function or on a scheduled basis.

Timeline:

date process and goals comments
Nov 6

  • Receive ATTinies to manage module processing
  • Receive RF wireless communicators to connect from modules to RPi.
 
Nov 13

  • Be able to communicate with the modules. Send basic Hello World messages back and forth.
 
Nov 20

  • Be able to make the modules act on physical things.
  • Have a working interface to control the modules
 
Dec 8

  • Prototype debugged and working. Report Submitted.
 


Materials Needed:

qty item with link unit cost comments
5 ATtiny85 ~$3 I believe Tom said he has some of these.
Team Alpha – Prototype II: TrueView Camera System

Description of Idea:

The TrueView camera system will be a complete and comprehensive viewing system for power chairs that will allow for safe 360 degree viewing operation in virtually any environment. The TrueView system will come with a rear camera that will allow the user to have a live feed of anything that may be behind the chair and it will give accurate and automatic distance detection to any objects that may be too close. The rear camera object detection will have the capability to work in the closest quarters of the home and will even be able to detect objects in the dark. The camera system will also have a powerful 3 dimensional axis rotating servo mount that will allow full 180 degree range of motion to detect items at all angles to include objects on the ground and uneven curbs. The TrueView system will also come with an optional front mount camera setup with the same powerful servo mount but will also come with greater distance viewing capability for those with limited vision or range of motion when looking straight ahead such as when crossing busy intersections. The TrueView system will have all of these features controlled by a simple easy to use interface mounted conveniently on the chair without the possibility of obstruction to arm movement. The interface will use an intuitive touch interface that will allow easy and stress free operation of both the front and rear cameras even while moving so that objects such cars moving towards the user from the rear will be seen and alerted with ease. The TrueView system is the most complete and versatile safety camera system available and will revolutionize the concept of full mobility for those using power chairs.

Description of Prototype:

With our first prototype we were able to successfully get distance detection working with the available Freenect libraries. Since this was achieved our next big goal will be automatic object detection. We would like to utilize the distance detection capabilities to detect objects that come within a certain distance of our camera automatically by setting up parameters that allow a safe and early warning to the user of anything that may cause a collision. We would also like to use this capability to setup a system within the software that will give a set of x and y coordinates to that object that has been detected nearby. This x and y coordinates will be used as a variable to pass to our servo system that will direct the camera automatically towards the object in question. We would also like to update the interface for the camera system to show only a high quality live feed of the objects behind the user without anything distracting such as the multi-colored demo used in prototype I. This would also include converting the use of meters to feet so that it will be more user friendly towards our American users of the system. We also would like to plan for our front camera interface that we will be using in conjunction with the rear camera system and plan on how the two interfaces will be working together.

Should we reach the benchmarks for prototype II that we have planned we estimate that the major key point of getting everything completed in the project will involve getting the distance detection software to work with the servo system. There will likely have to be two services running on our control computer at one time and the distance detection software will need to communicate between the two. The distance detection software will need to take the x and y coordinate values that we have initialized with our prototype II design and then pass those variables to the Arduino controlled server system in an efficient and quick manner so that the camera can lock onto the object in question. The other thing we will have to contend with after prototype II benchmarks are met will how we plan to interface the front and rear camera. We have been planning to have to separate feeds that will be easily switched from a touch screen interface but we still have more work to do until we decide that.

The goals we set to measure success are as follows:

1. Camera can detect object at given distance parameters in less than .25 seconds and produce notification.

2. Camera can produce x and y coordinates to the object detected as fast as possible. Hopefully less than 100 milliseconds.

3. Camera can detect and give accurate distance and coordinates to within 50 cm.

4. Object detection of the camera will be able to negate trivial items. For example, a tree limb that is merely a quarter inch in diameter that may be easily run over by the chair should not trigger an alarm.

5. Another future goal that we may or may not be able to address for prototype II is the ability of the system to run on its own power for at least 5 hours. There is an interest by our team and by residents viewing the object at the trade show for an independent power source that will not draw whatsoever from the main chair power. We feel that this is very good point and we would like to start studying power requirements for this system.

We have yet to determine the overall cost for our goals because we have not optimized the camera system to run on anything other than a laptop. There are great possibilities for code and process optimization that we have already discovered. Our goal to be able to produce a full working model of our setup for less than 300 dollars with functioning touch interface and front and rear cameras in place.

Timeline:

The below table is just an example for how you might do a timeline. Content in the table is also just example content. Feel free to change and restructure the below table as you wish:

date process and goals comments
Nov 6
  • Get the kinect to scan for the nearest object.
  • Condense the code.
 
Nov 13
  • Get the kinect to send the (x,y) coordinates to the servos and spit them out on the screen
  • Continue to work on getting the kinect to scan for the nearest object
 
Nov 20
  • hardware and software working together, although perhaps not robust yet
  • Get the kinect mounted on the servos
 
Dec 8
  • prototype completed, working, report submitted
 

Materials Needed:

qty item with link unit cost comments
1 XBox Kinect 150.00 XBox version works but Microsoft developer version does not.
1 Kinect Power Adaptor

8.00

Is not provided with standard Xbox Kinect
2 Servos 5.00 More may needed later depending on progress.
1 Breadboard 10.00 Project board for front servo mounts
1 Laptop 0.00 Provided by department. Needs Ubuntu Linux for Kinect Libraries.
Marz – Prototype II: Campus App

Description of Idea:

We are working to develop an interactive smartphone app/website for college campuses. This app provides ways for any college student to network on their campus as well as assisting them in finding specific information regarding any groups, activities, events, and classes that they may need.

The app contains an interface comprised of layers that the user can choose to enable that displays different topics. One layer is the “Campus” layer, which displays a map of their campus and the surrounding buildings on campus. The app would be GPS-enabled, allowing the user to see exactly where they are in relation to the class that they are about to be late for. Another layer, the “Groups” layer, superimposes on top of the Campus layer and displays icons on the tops of buildings that show where these student groups meet. The user can double-tap on any of these icons to find out more about these groups, such as meeting times, contact information for the group leader, upcoming events within the group, or other group announcements. The “Classifieds” layer provides a way for students to post information about books they would like to sell, roommates they need, or furniture that needs a new home. (The current way to do this is to post flyers on the boards throughout the buildings on campus, which are only seen by a small percentage of the student population. Anyone can just get on the app and scroll through a sectioned list of classifieds find what they are looking for.) This app will allow for scalibility by allowing schools to create their own layers. For instance WSU students could use a “Construction Detours” layer to avoid the mess surrounding RSC and plot the quickest route to their destination.

The hardware portion of this idea consists of outside modules (similar to the ones at the zoo) that activate when the user goes near them with the app open. The user presses a button on the app, which will then begin “talking” to the user, giving the them a description and history of the building, artwork, statue, or other landmark on campus. This would be great for orientation leaders who spend all day trekking across campus with new students, and would provide an excellent means to display outdoor sculptures. Any time they forget information about something or just need to take a break, they could activate a module let the app talk for them! New students that do not want a campus tour can use this app to help them navigate the campus. A website for all this would be available as well. The website is referenced by the app, but could also be used directly if users are unable to use the app. We will create a web server to give the app a database and functionality.

We think that this is a great idea that could be implemented on almost any campus worldwide. The modules would be programmable and the layers could all be modified by an administrator so that each campus could choose what layers they want to implement. A few years back, WSU attempted to create a networking website for students. As a website, it did not catch on because there were few activities listed and very little interaction was provided. It was not well publicized and just did not get enough users. We feel that with the proper showcasing and development, this app could be a hit not only for new students, but for faculty, staff, parents, and graduates alike.

Description of Prototype:

Our first prototype consisted of getting a web host and a database setup, along with a basic menu and a single module up an running that would display a map of the school. Our next prototype will consist of adding a login/registration system so that students can personalize and interact with the app. We will enhance the map module to display building information when clicked on the map.

There are many modules we could work on, but we have enough time to complete about 2 and we chose the most popular ideas from our survey. We will implement a Classified module that will allow students to post items they want to sell, find room mates, or other miscellaneous topics. These posts will (ideally) be reviewed by the administrator for content and then posted onto the classifieds board. We will also implement an Events module that will display upcoming events that are submitted by the school. Students and student groups will also be able to post sanctioned events after an administrator reviews and approves them.

Finally, an Administration module will be created that will allow the administrators of the app to manage the content and change settings. The module will be able to configure and manage all the modules for our prototype: Map, Classifieds, and Events.

Timeline:

date process and goals comments
Nov 6
  • Registration and login scripts completed
  • Building info links on map module finished
 
Nov 13
  • Classified module completed and outside sources able to post information on the classifieds
 
Nov 20
  • Event calendar module complete
 
Dec 8
  • Administration module to modify the map, classifieds, and event calendar module completed
 

Materials Needed

Item Cost Comments
Web Server $0 Already have a web server set up through a free web host.
Android Phones $0 Three group members have phones for testing; emulation is also available.
Infinite loop – Prototype II: [Emergency warning system.]

 

Description of Idea:

One of the CPRF administrators, Tara, had informed us about the lack of a suitable emergency warning system around the CPRF campus and how much such a system would come in handy, especially during harsh weather conditions such as tornadoes  we therefore came up with the idea of a multi-colored LED-based warning system that the administration can use to inform the residents of imminent adverse weather conditions and danger within the compound. the administrators will be able to remotely activate the brightly colored LEDs( that will be strategically placed on top of tornado shelters) though their cell phones or computer. This will be visible to all residents and direct them to the shelters. based on a predetermined scheme, certain LED colors will correspond to  specific emergencies while others will be used to indicate the intensity of the emergencies.

Description of Prototype:

our first small scale  prototype involved an RGB LEDs controlled by three separate switches, and powered through an arduino. the three switches produced red, blue and green lights respectively and we were able to get several other colors by turning on more than one switch. This prototype was already in line with what our CPRF correspondent was looking for; color coded emergency system that the security guard could turn on from the shelters. however we are adding several modifications to this for the second prototype. First of all, we are implementing an LED what should be visible from all corners of CPRF, which will require more power than the basic arduino can handle. we will therefore implement several transistors into out current prototype to amplify the current, in such a way that the LEd can be powered but the arduino will not burn out. 

In addition to the conventional switches, the new prototype will be controlled remotely, either through sms, email or a website.  Therefore there will be much more programming and software involved in the second prototype. The interface will also be accessed wirelessly so we will add an Ethernet shield onto the arduino. 

AS discussed, the color schemes will be determined after further discussion with Tara from CPRF and by December 6 we should have a working prototype of one of the LEDs that will ultimately be placed on top of each tornado shelter. we are still in discussion as to weather we should include an alarm sound system to go with the LEDs

Some of the measurable things the prototype will be able to do is:

1. Allow control of the leds from whatever distance

2. The led should be visible from the same distance as the distance from each shelter at CPRF to their perimeter

Timeline:

 

date process and goals comments
Nov 6
  • order arduino shield.
  • come up with complete structure template.
  • complete follow up interview with Tara
 
Nov 13
  • initial Arduino programming complete
  • skeletal structure complete
 
Nov 20
  • hardware and software working together, although perhaps not robust yet
 
Dec 8
  • prototype completed, working, report submitted
 

Materials Needed:

qty item with link unit cost comments
1 ethernet shield 47.00 any shift register OK
1 arduino uno 30 any Arduino OK, including older Arduinos
1  mounting box    
       
       
       
       
       
       
[JEL] – Prototype II: [Operation Freedom]


Description of Idea:

Our idea is to create a device that acts as a relay that is controlled by one simple switch. Our device will extend the freedom of our client who is wheelchair bound as well as incapable of communicating verbally. Currently our client is unable to switch rapidly between the abilities to control his chair and communicate using his communication board. Our clients’ unable to do this due to the fact that each of his devices are control by non compatible switches which leaves our client to be reliant on care givers to change out each respective switch when it is necessary.

Description of Prototype:

Our current prototype manifests itself into two different forms, a wireless (bluetooth) form and a wired form. In the wireless form we  have decided to use a Raspberry Pi as the relay itself. We chose the Pi due to its’ low cost and power. Since our prototype I consisted mainly of solving unknowns our prototype II will consist of implementing solutions to our problem utilising the knowledge we gained solving our unknowns.  Since we now know that our client’s bluetooth switch acts as a serial port emulating server we must implement a serial port emulating client to communicate with it (asynchronous RFCOMM socket programming). Once we are able to reliably  obtain the information sent from our clients’ bluetooth switch we will implement a serial port emulating server that will relay the data sent from the switch to our clients communication board (which happens to be a serial port emulating client). Once these two tasks are implemented we will have to experiment heavily with our implementation to minimize any bugs or glitches we can find. If all goes well our relay should never lose connection or fail in anyway. Once we have secured our server and client we will easily be able to extend the functionality of our relay. Since we will be able to intercept the data sent from our clients bluetooth switch we will be able to easily redirect that data to other outputs e.g. a wheel chair. Since we have most everything we need for this solution its’ cost should only be in time.

The wired version of our prototype II consists of a switch controlled by our client that is connected into an input of  a circuit/arduino that we have designed. There are two outputs from the circuit/arduino, one of those outputs goes directly to the wheel chair motor, this will allow our client to control his wheel chair. The other output of the arduino will be wired into our clients bluetooth switch. The hope is that this wired output will trigger the bluetooth switch to send data to the communication board of our client without actually physically manipulating the bluetooth switch. You can see a demonstration clicking the link. Our client will be able to change modes by double or triple clicking his switch.

 

Timeline:

 

date process and goals comments
Nov 6
  • Wired soultion tests have taken place for a week
  • Implement RFCOMM client in python 2.7.x for wireless solution
  • complete interviews with target consumers/consumer groups
 
Nov 13
  • Implement RFCOMM Server to test accuracy of data sent by relay
  • Meet with client
  • Experiment with implementations
 
Nov 20
  • Build a box for Raspberry Pi
  • study which output of Pi would best be suited for Wheel Chair input, (GPIO pins, audio outs)
  • Debug wireless solution
 
Dec 8
  • prototype completed, working, report submitted
 

Materials Needed:

Currently unknown.

Group 3 – Prototype II: Battery Range Meter

Description of Idea:

The battery range meter is a device that can be attached to any electric wheelchair and be able to give a read out of how far it can travel based on the charge.  

Additional components may include:

  1. A GPS feature that can get your location and input where you are going and based on this information tell you if you can travel there.
  2. A USB port you can use to charge your phone.
  3. Display other information such as average speed and time between charges.

Description of Prototype:

Prototype II will be an extension on our first prototype by adding the ability to measure the current from the battery, health of the battery, and speed of the chair.  We can us this information to make a generalized equation of battery remaining and distance you can travel.

Currently, our device only measures the voltage and we use this information based on our test chair to convert that into a distance based on testing we have done.  The main drawback of this is our prototype can only work on that specific chair, that specific battery health, and only on full speed.  We want to broaden that scope to work at any speed and hopefully any chair.

After adding these capabilities, our full idea will be adding bells and whistles to make the project more marketable, and putting it into a small size that can actually be added to a chair while looking professional.

5 measurements are:

  1. voltage of the battery with a load
  2. current coming out of the battery
  3. speed of the chair
  4. GPS location
  5. range

 

Timeline:

The below table is just an example for how you might do a timeline. Content in the table is also just example content. Feel free to change and restructure the below table as you wish:

date process and goals comments
Nov 6
  • Order new voltage and current sense break out chip
  • Order GPS chip
  • Test data-logger
 
Nov 13
  • Attach components and test them in lab
  • Get code together for components
  • Research methods to obtain battery health
  • Research information about battery life/amp output
 
Nov 20
  • Come up with generalized equations for the range
  • Test accuracy
 
Dec 8
  • prototype completed, working, report submitted
 

Materials Needed:

If you are needing EECS to provide materials for you, list them here. We can then work out how to obtain these with our reimbursement policy:

qty item with link unit cost comments
1

AttoPilot Voltage and Current Sense Breakout – 90A

19.95 Replacement
1 Arduino GPS Shield 55.00 Used for location and speed
1  Ultra Plug, Male  3.55 Connects to Voltage and Current Sense
1  Female Ultra plug to leads  5.99  Connects to battery