Archive for the 'Prototype II' Category
Team Bravo Squad- Progress Report for Prototype II: Emergi-Text (4/17/13)

Goals for the week: 4/17/13

Our goals for this week are to finish our box for the Emergi-Text device.  Construction for a box has been started and needs to be completed. A larger button needs to be built for easier access of use.

For the program being used for our device, there needs to be some debugging for the battery disconnect application. When power is lost for the device, the Emergi-Text app should automatically turn on and send out a text to a friend for family member.

Meeting times/dates

Tuesday 1pm – 2pm 

Thursday 11am to 12pm

Individual Hours:

Bryan 1 hours soldering wires together

Tanner 1 to 2 hours debugging programs for the Emergi-Text app. Tanner worked on the program for the power disconnect and continues to fix any problems the program might have.

Danny 1 to 2 hours finishing contacts list for program. Programing the contact list into Emergi-Text app on device.

Ryan 1 to 2 hours designing and building a box for device

What we did:

  • Soldering wires together
  • Soldering wires to circuit board
  • Cut materials for box
  • Finished button setup for device
  • Power disconnect program
  • Emergi-Text contact list was programmed into app
  • Debugging for button program

What we didn’t do:

 

Where we are stuck:

For some reason our Emergi-Text app will work fine when the button is pushed, however when there is a power disconnect to replicated a dead battery the app on our system will crash. Further inspection of this issue is in progress and should be fixed by Monday. 

 

Notes/Misc:

 

Goals for the week: 4/11/13

Our goals for this week are to finish our box and button for the Emergi-Text device.  Construction for a box has been started and needs to be completed. A larger button needs to be built for easier access of use.

For the program being used for our device, there needs to be some debugging for the battery disconnect application. When power is lost for the device, the Emergi-Text app should automatically turn on and send out a text to a friend for family member.

Meeting times/dates

Tuesday 1pm – 2pm 

Individual Hours:

Bryan 2 hours soldering wires together, cutting materials for the box

Tanner 1 to 2 hours debugging programs for the Emergi-Text app. Tanner worked on the program for the power disconnect and continues to fix any problems the program might have.

What we did:

  • Soldering wires together
  • Soldering wires to circuit board
  • Cut materials for box
  • Started building a button
  • Power disconnect program
  • Emergi-Text gps coordinates programmed to be sent when device is on
  • Debugging for button program

What we didn’t do:

Bryan could not get any solder to stick to the pin being used to plug into the phone. The pin is made of a stainless steel and the silver solder will not hold.

Where we are stuck:

 

Notes/Misc:

Team Bravo Squad – Progress Report for Prototype II: Emergi-Text System

Goals for the week: 4/3/12

Bryan’s goals for the week are to get a box built for our Emergi-Text device. He will make a model of the box first and then design the box on the computer and have the laser cutter cut the box to piece together. Once the box is built a button can be installed or made.

Programming goals: For the programming code Danny has been working on the contact list that can be used for our device. Tanner will be doctoring up his section of programming. All the code is now being shared between Tanner, Danny, and Ryan for further collaboration.

Meeting times/dates

Tuesday 1pm to 2pm

Thursday 11am to 12 pm

Individual Hours:

Bryan spent 1 to 2 hours modeling a box out of foam board and then began drawing up the box digitally for the laser cutter

Tanner spent 1 to 2 hours fixing problems with code and creating new features with our system

What we did:

We have begun final stages of our device, so full manufacturing and usability will soon be available. A box with a large easy button is being built and the final strings of code are being written.  

Where we are stuck:

Our app that we are creating will crash every so often, so we have been dealing with that and trying to figure out why the phones program this our app has less priority than other apps. When we use the push button feature the app should automatically come on and send a  message, we are having trouble with this being consistant.

 

Goals for the week:3/27/13

Our goals for this week were basically the same as last week. We are still working on the code for our program.

Tanner is dedicated to the code that responds to the power output of the wheelchair.

 Danny is dedicated to the code for the contact list for the device. 

Ryan is dedicate to the code for the button control that turns our device on.

Bryan is constructing  a larger button for easier use for the  electrical components to the device.

Meeting times/dates

Tuesday 1:00pm to 2:pm

Thursday 11:00am to 12:00pm

Individual Hours:

Tanner spent several hours 2-3 hour on programming his portion of the code

Bryan spent 1 hour setting up electrical components to the device. The usb port that goes into a power socket similar to a car’s power port was tested.

Ryan spent a couple hours getting examples of how to re-program a media button for a phone. He found several examples that may work.

What we did:

Tanner was able to get the app for the Emergi-Text system to actually function. There still needs to be some minor tweaking, but for the most part we have a working app for the device.

Bryan spent some time designing a box for the device as well as constructing a larger button for the device. The button is not completed but should be finished by next week.

What we didn’t do:

We were not able to have our program run continuously for our device. There may be an error in the code, but the app continues to crash after being turned on. The function on the phone put the media button at a higher priority than the function Tanner programed it for.

Bryan was not able to get a box built to hold all the electrical components to our device. The lab has been full this last week so space for work has been hard to find. The design for our box and button have been design, but need to be built now.

 

Where we are stuck:

Not stuck so much as waiting for code to be written. Bryan’s work is dependent upon Ryan’s code and in order for Danny’s code to work Ryan’s code must be written.

Bryan needs to solder a couple wires from our power source to the usb port.

Notes/Misc:

Team Bravo Squad – Progress Report VI for Prototype II: Emergi-Text

Goals for the week:

Tanner- Continue working on his program for the button being used to turn on the Emergi-Text system, which will be sending a text to a contact of choice

Danny- Begin programming the code for the contact list being used in the Emergi-Text app

Ryan- Begin working on a code to read and display to amount power being used or remaining in the wheelchair.

Bryan- to test the stripped down earbud wires to see which wire and ring on the pin  are being used for the button to turn the microphone on and off

Meeting times/dates

Tuesday 1pm to 2pm

Thursday 11am to 12pm

Individual Hours:

Bryan 1 hour of stripping down wires and testing the I/o of each wire to understand how the ear buds worked.

Tanner 1 hour of programming

Danny 1 hour of programming

Ryan 1 hour of programming

What we did:

Bryan spent time this week carefully taking apart a pair of ear phone with a mic button. The button on the ear phone is the main focus of this process. We will be using the wires to the button and the pin that goes in to the phone port. We stripped it down and found out that the first two ring on the bottom of the pin are used for the left and right audio, the third ring appeared to be the ground which were gold wired and the microphone wire was attached to the top ring or sleeve. We are mainly only needing the red and gold ground wire for this project. The audio wires serve no purpose for the system.

 Tanner order more parts for the project. He ordered several usb jack that can be plugged into a cigarette lighter, and ordered a cigarette lighter port that can be wired directly to the wheelchair power source.

Danny began working with the code for the contact list being used for our system. We will be using our own personal phone numbers until a client is set up for this product.

What we didn’t do:

We have still not purchased a test phone, but this is not top priority since the programming is not even ready for the phone yet

We have not worked on designing a way to test the remaining power in the batteries.

Where we are stuck:

Where we are stuck the most is just trying to figure out tedious coding for our program. The program for this project is definitely the hardest part that needs to be designed. We are not even sure yet if we will be able to even re-write new programs into phone or not to turn on the emergitext system through the push of the ear phone button. The app on the users phone should work fine, it is the phone we will have to used for the button that we have concerns with.

Notes/Misc:

Team Bravo Squad- Progress Report V- Emergitext

Goals for the week:

The goals for the Emergi-Text system are primarily set towards programming this week. Tanner, Danny, and Ryan have downloaded git and will be focused on individual projects for the programming. Bryan is focusing on the production of the circuit design.  

Meeting times/dates

Tuesday 1:pm

Due to the weather we mainly communicated through email

Individual Hours:

Tanner 1 Hour

Danny 1 Hour

Ryan 1 Hour

Bryan 1 Hour

What we did:

Danny has began working toward his individual goals toward setting up the program for the contacts list in the Emergi-Text system. Danny made a youtube video for setting up the git account.

Tanner worked on the automated battery monitoring program

Ryan has begun working on the manual functionality of the system, which is basically programming the button functionality which will be turning our device on and off and then sending out emergency text

Bryan setup an initial circuit design which now need to be tested and built on a circuit board.

What we didn’t do:

Due to the weather we were not able to distribute the headphone Tanner purchased to each other. Bryan will be stripping a pair of headphones down to see how to connect the button to the device, and Ryan will be testing the button to see what steps need to be taken to program the button.

 

Team Bravo Squad – Progress Report IV: Emergi-Text

Goals for the week:

Our main focus for this last week was  to  have Git downloaded onto Danny and Ryan’s computers so Tanner could collaborate with them. Once a gitorous account was made then the fine tuning through eclipse could be made to our programming code. Bryan’s goals for the week were to come up with or find a circuit design to step down the 24v from the wheelchair to 5v to the usb cable used for the device we are using.

Meeting times/dates

Tuesday 1pm to 2pm

Individual Hours:

Tanner spent 1hr on programming as well as setting up a tutorial for our group showing steps on how to download Git and eclipse

Danny spent 1hr on creating a gitorous account

Ryan spent 1hr creating a gitorious account

Bryan spent 1hr  searching for circuit designs as well as working with a wiring a bread board for a basic set up of our circuit

What we did:

This week Tanner ordered four sets of headphones which we will be using for the push button function. Bryan checked out a breadboard to begin setting up a circuit that can be used to connect the power from the wheelchair to the Emergi-Text device. Danny and Ryan began setting up their sections of programming. Collaborations between programming is now enabled between Tanner, Danny, and Ryan. Each programmer will now program specific functions of the device.

What we didn’t do:

We have still not been able to buy a smartphone, but that is not really top priority right now. We have not been able to find a way of testing our voltage regulator circuit. We would like to be able to test our circuit without connecting it to someone’s wheelchair.

Notes/Misc:

Three Musketeers – Prototype II Final Report: Laser Tag

Introduction:

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 communicated via WiFi to central server, which processes the data and outputs game play statistics.

Description:

What did you build? How did you build it? Be as specific as possible. Include pictures and or video that directly illustrate description. Give enough explanation that somebody of your capabilities could duplicate your results. A step-by-step set outline of what you did is appropriate.

 The device consists of an Arduino Uno that collects data from a GPS and Magnetometer and sends the data wirelessly to a router using a WiFly Shield. Most of this is safely stored inside a box custom designed for the Arduino.

The Arduino code is a simple program that collects Data from the GPS and Magnetometer and sends the data as an HTML page to anyone who requests one.

The server program is coded in Python 2.7 using the following libraries: Pygame, Twisted, Zope.Interface, PGU-0.1.8 (pygame gui). The program uses Twisted’s reactor as the base, which periodically calls PGU’s event handler. The reactor controls networking and realtime scheduling and the event handler controls the GUI interactions and rendering. A flow chart of this activity is shown below.

This program is designed using the core structure of Andrew’s multiplayer game from another class. This core structure provided an asynchronous reactor with networking and GUI support. A simple functional GUI was added and then data was retrieved from the Arduino at 2 second intervals.

Here is the code: http://cratel.wichita.edu/blogs/eecsseniordesignfall2012spring2013/forum/teams-group2/2-three-musketeers-forum4/prototype-server-code-and-setting-up-python-thread166/#postid-491

Diagrams:


Cost Report:

Component Qty Unit Cost Total Cost Comments

 WiFly Shield

1

$69.95

$69.95

 

 arduino uno

1

$30.00

$30.00 

 

 Compass Module – HMC6352

1

$34.95 

$34.95 

 

 Resistor assortment

$7.21 

$7.21 

 

 

 

 

 

 

TOTAL     $142.11  

Reflection:

In the first prototype we created a device that tracks position and heading. We had a problem with the accuracy of the measurements from that device so we replaced it with new parts. In the second prototype we broadcasted the data wirelessly to a router which then can send the data to a server. In addition to the expected prototype II, we have created a program that provides limited GUI and receives the data from the router. We are currently having problems establishing reliable communication with the device, but it appears to be a coding issue. From here we just need to setup reliable two-way communication between the server and the device, create more client devices, and implement game play functionality.

Out of Time – Prototype II Final Report: Cool TEC

The Cool TEC Pad

 

Introduction:

For our design project we talked with residents at the C.P.R.F. facility and found that nearly everyone we talked to felt they would find several uses for a pad that had the capability to be hot or cold. They also stated that different style of pads would be a great addition to the design. Using all the comments that we gathered we decided on a  unit that would use a water circulation system to circulate water through a pad that could be used by the clients. After several design options we decided on making the system based on two parts. The first would have the water circulation parts as well as the temperature control devices. The second would be a pad that the user could place wherever they needed.

Description:

The hot/cold pad we have designed is a temperature controlled water circulation pad. The temperature adjustment device we used is a thermoelectric cooler ( also called a Peltier Coooler). When electricity is applied to it, one side gets cold while the other side gets hot.  A Peltier was chosen because of the simplicity of its design and the lack of any moving parts. Through research of the units we found that to work efficiently there would need to be something on the hot side of the unit to pull the heat away from the unit. Without something to reduce the heat of the unit, the effectiveness would be lost to the heat. To solve this we purchased a Liquid CPU cooling unit on the hot side to reduce the heat exposure. The CPU unit was rated to handle the heat we would be dealing with, and would save us the time it would take to develop a hot side cooling system. To be able to circulate the temperature we wanted from the cold side of the Peltier Cooler we fabricated a water block from a heat sink unit of an old computer. We decided to fabricate a water block due to the cost of ready made water blocks, which would put us over budget.  The top was cut off of the block, then we epoxied acrylic plates to the top and sides to contain the water. to circulate the water through the block we drilled 3/8″ holes on both sides of the block and welded copper tubing into the each whole for connecting the water tubing. After connecting the tubing together we attached a submersible water pump to the cycle that would circulate the water through the system. Once this was finished we focused on a power supply for the system. A computer power supply was what we decided to use, and found one that would supply up to 18 amps at a regulated 12.0 volts. This would be sufficient power to supply all the components of the project. A custom or more specific supply will be required in the future, but this one was readily available and free. We disassembled the power supply to remove all unwanted wires, and soldered on wires that we would use to power the unit. After completing all these pieces we attached a pad we acquired from online research that would efficiently supply the wanted temperature to the user.  This pad was designed for use in veterinary hospitals, helping control animal body temperature after surgery.

Diagrams:

 Thermoelectric Cooler (Datasheet)                   CPU Cooler

                              

         Water Circulation Pads                               Water Pump

      

 

Peltier Cross-Section

 Project Design Overview

 

Cost Report:

Component       Qty Unit Cost Total Cost Comments
Thermoelectric Cooler                    1 $10.95

$10.95

 Several different options available 
Water Pump $11.50 $11.50  
CPU cooler 1 $54.99 $55.99  Bought used
Water Circulation Pad #121218 $32.00  $32.00   Used for veterinary medical services  
         
TOTAL     $110.44   

Reflection:

As much as it helped us out in the final stretch, we are going to try avoid using epoxy in our final project (at least for least prevention).  We believe that most pieces of the final device will have to be fabricated from scratch.  These pieces do exist in the real world already, but budget constraints will prevent us from buying everything.  Due to the fact that we are focusing on water circulation, we are going to focus on making the final device for in-home use, and not be portable.  This will allow us to purchase a larger Peltier cooler, and provide better heating/cooling capabilities.

We believe next semester will show much more progress.  Now that we know what we want to do and how we want to do it, we can hit the ground running.

 

Sources:

http://garagelab.com/profiles/blogs/how-to-use-a-peltier-with-arduino 

http://www.benchtest.com/wcooler1.html

https://sites.google.com/site/arduinotempcontrol/ 

http://www.dansdata.com/pelt.htm

http://www.amazon.com/gp/product/B002UQ150Q/ref=oh_details_o04_s00_i00 

http://www.amazon.com/Brushless-Submersible-Water-Ideal-cooling/dp/B0051HI3OM/ref=pd_sbs_indust_1 

http://www.amazon.com/Corsair-Cooling-Hydro–High-Performance-CWCH60/dp/B004MYFOE2/ref=sr_1_1?s=electronics&ie=UTF8&qid=1348797987&sr=1-1&keywords=Corsair+Cooling+Hydro-Series+All-in-One+High-Performance+Liquid+CPU+Cooler+CWCH60

http://www.paragonmed.com/warmsys.shtml

http://bildr.org/2012/03/rfp30n06le-arduino/

http://en.wikipedia.org/wiki/PID_controller 

https://github.com/br3ttb/Arduino-PID-Library

https://github.com/osPID/osPID-Hardware

http://www.brewpi.com/

http://www.homebrewtalk.com/f51/temperature-monitoring-control-arduino-155408/

http://electronics.stackexchange.com/questions/28634/how-to-drive-a-peltier-element

http://provideyourown.com/2011/analogwrite-convert-pwm-to-voltage/ 

http://www.zen22142.zen.co.uk/Circuits/Power/3730.htm

http://arduino.cc/en/Tutorial/SPIDigitalPot

Team 9 – Prototype II Final Report: Remote Piano Pedal Controller

 

Remote controlled piano pedal

Project Overview

 

The project is designed in order to return dynamic control of a piano pedal to someone who has lost the use of their legs. The technology available at this time utilizes a solenoid operated system. Solenoids operate in an on/off manner and don’t allow for the subtle movements that a professional piano player executes.

    Using an infrared sensor to realize the player’s analog input, a cam is operated that delivers an analog response to the piano pedal.

Description:

Positioning feedback mechanism

Figure 1 shows the mechanism that was designed to produce positioning feedback. The red gears connect the cam to a potentiometer at a 1:1 ratio. A potentiometer is a device like a volume control knob. It takes a 5v signal and returns a value 0-1024 based on whether the ‘volume’ is turned up or down.  As the motor turns the cam, the potentiometer also turns. This information is delivered to the arduino at input a0. The red gears were printed on a 3 dimensional printer from a pattern that was created on google sketchup. The white hub was turned on the shop lathe. A felt clutch is incorporated to allow the potentiometer to slip when it reaches its minimum and maximum limits. This allows the unit to be easily calibrated to a large variety of pedal heights.

 

Rotary actuation mechanism (Cam)

 

Figure 2 shows the cam that pushes the pedal down. The vertical linear range realized by the cam is 0 to 2 inches. This allows the system to be used in a variety of settings with very little adjustment required. Assuming normal piano design and setup, pedal depression ranges from 0.75 inches to 2.0 inches. Inside this range, there is approximately a 30 – 40% area of free travel at the top of the stroke. This is an area where the felt pad (damper) is coming closer to the string but is not close enough to have an effect of the string. Similarly, there is approximately a 25% area of travel at the bottom of the stroke where the damper is in complete contact with the string and further depression does not alter the deadening effect. This gives us an area of 35 – 45% in the middle of the stroke where the player will be using the feathering effect that the cam delivers.

 

Infrared user interface

 

Figure 3 shows the infrared interface that the player uses to manipulate the system.  The sensor sends out an infrared pulse and uses the echo response to determine distance. This information is sent as a voltage output returning an integer in the range of approximately 50 – 600mV to the arduino at input a1. This information is used in conjunction with information received from the positioning mechanism to move the piano pedal to the desired position. The sensor is shown here mounted to the system frame. In practice, the sensor can be placed virtually anywhere based on the user’s needs. For example, the sensor could be placed on the side of a user’s chair to read the distance to the user’s thigh.

 

Arduino micro-controller

  

Figure 4. Information received at input a0 from the infrared sensor represents the players desired pedal position. This value (50 – 600) is compared with the value (0-1024) received at input at a1 which represents the pedals current position. As the two numbers are compared a0 – a1 = command value. A command value > 25 sends a current through +M2 which causes the motor to move forward. As the motor moves forward, the cam moves down depressing the pedal and the potentiometer value is altered. When the two values agree a0 = a1 the current ceases and the motor stops. Similarly if the command value is < 25, a current is sent through –M2 which causes the motor to move backwards until the two values match.

 

Arduino code

 

 

Wiring Diagram

 

Demo Video


http://www.youtube.com/watch?v=dTsL8y2Sbow&feature=youtu.be

 

Cost Report:

  Qty Unit Cost Cost per 100 units Min Qty Comments
Arduino Microprocessor 1 $45.70 $4,570.00 100  Item may be purchased online
12 DC Motor 1 $44.75 $4,475.00 100  Item may be purchased online
H bridge motor shield 1 $20.00 $2,000.00 100   Item may be purchased online
Teflon Cam 1 $40.00 $4,000.00 100  Custom order machined item
Infrared Proximity Sensor 1 $14.95 $1,495.00 100  Item may be purchased online
Gears 2 $2.00 $200.00 100 Similar gears available online
Potentiometer 1 $1.55 $155.00 100  Item may be purchased online
TOTAL   $170.95  $17,095.00     

Reflection:

     The project seems to solve the problem as anticipated. A clutch system was added to the initial design in order to protect the gears. This addition allows the end user to callibrate the system very easily. In addition, the pedal controller needs no adaptation to make it  a viable solution for people who are unable to use a sewing machine pedal or any other type of linear accelerator.

The next phase of developement will include:

  • tightening up some of the parameters to fine tune the sensitivity and speed control.
  • designing a quick installation mechanism.
  • aesthetics of the finished device.
  • developing circuitry to replace the functionallity of the arduino interface and bring the unit price down.
[Team Name] – Prototype II Final Report: [Title of Project]

Introduction:

CPRF staff contacted us and requested a hazardous weather warning light system to keep their community informed and safe during bad weather. Our solution is implementing RGB LEDs controlled by Arduinos connected to a master server.  The lighting system is designed to be modular and will eventually be mounted on three towers to make it easily seen by the CPRF community. By varying the voltage sent to each color of the Light-Emitting Diode (LED), we can control the LED color. The three different colors are intended to be used with different level of weather severity. If there is a severe weather condition, the red LED will be turn on to urge the residents to go to shelter. The blue LED is to make aware the community that there will be a weather watch. And lastly, the green LED turns on when the weather warning and/or watch is cleared. These color combinations may be modified at a later date.

Our hazardous weather warning light system is a helpful addition to existing weather alert systems. Members of CPRF community who would be otherwise unaware will be able to stay informed about dangerous weather.

Parts used for this project are as follow:

RGB LED array: a single LED is small in size and by itself would not be bright enough to see it from a distance. The solution is to combine multiple LEDs in an array which can be more easily be viewed.

Arduino microprocessor: to recognize input signals and turn on the various colors of the array.

Load Resistors: to limit the amount of current flowing to the LED , this prevents the LED from burning out.

Computer: to provide remote input to the arduino.

Box: to hold the Arduino and power supply.

 

Description:

The Hazardous weather warning system is designed to control Red, Green, and blue LEDs. The RGB LED will be mounted in a tower and controlled from a server connected to the Arduino.  To achieve this we implemented a driver circuit that controls the amount of current going to the LED. A 32 Volt transformer provides DC power to each color of the LED, each color has a MOSFET controlling the flow, the Arduino inputs a signal to this switch turning on the array. To prevent burn out, the there is a load resistor in conjunction with the MOSFET. 

 

 

Disassembled LED array                                                                       Driver Circuit

 

 

 

 

 

 

 

 

 

 

Final housing and controller

 

Array in green mode

 

Array in blue mode

Cost Report:

 

Component

Qty

Unit   Cost

Total   Cost

Min Qty

Comments

LED

1

$82.00

$82.00

1

 

Mounting Box

1

$8.00

$8.00

1

 

Arduino 

1

$30.00

$30.00

1

 

TOTAL

 

 

$90.00

 

  

Reflection:

We are able to operate the RGB LED from our computer, controlling each individual color. The project can be more expanded and improved by modifying the arduino input methods. Because it is a modular system these inputs could be expanded to a variety of forms, including email/sms control or other forms of remote input.

Group 3 – Prototype II Final Report: Battery Range Meter

Introduction:

Wheel chair users come across many issues in their day to day lives. One of the issues they have to deal with is the limited capacity of the battery on the wheel chair they use. Battery capacities are different due to many reasons including size, age or how well it is maintained. Due to these reasons, users have a hard time knowing how long he/she can use it before they have to recharge.  All wheel chairs in the market show some kind of a battery level but how does that translate into real life?  They do not display how far the wheel chair can travel before it has to recharge.

For our project, we are trying to address this issue and build a device that can display the traversable distance remaining on a charge. With this intention, we did some research and started finding a solution.  We are relying on the battery voltage to measure the charge. We have collected data about the distance our test chair can travel and how the voltage drops depending on the charge.  We are reading the battery voltage at a given time and calculating the distance it has remaining on the current charge.

The major components we are using:

  1. Arduino Uno – R3
  2. Basic 16×2 Character LCD – Black on Green 5V
  3. Parallax 28500-RT PMB-648 GPS SiRF Internal Antenna

Description:

Batteries and electric wheelchairs are not made equal.  In order to get accurate distance measurements for the wheelchair we used, data had to be collected.  We spend all day in a park running down the battery of our chair and taking voltage measurements along the way.  We started with the voltage of a full charge and collected measurements around every two miles we traveled to see the change. 

In order to translate this into a nice equation we can use to come up with a good judge of distance remaining, we had to change our limits to not include the full charge and dead voltage measurements.  In order to accommodate for this, we don’t allow the meter to display more than 18 miles or less than 2.  Once those we removed, we used excel to find a best fit curve. 

LCD Diagram:

The LCD on this version of the project is a basic 16 by 2 LCD.  This means it can display 16 characters by 2 rows.  The connections for it are shown in the diagram below.

 

LCD Tutorial and Source Code

Instructions:

  1. Connect Gnd and RW to potential meter and ground
  2. Connect Vcc to the 5V supply
  3. Connect Vs to the potential meter
  4. Connect E to pin 11
  5. Connect D4-D7 to D5-D2 respectively
  6. Connect V+ to 5V supply
  7. Connect V- to ground

GPS Diagram:

To add more functionality to the device a GPS is also included.  The GPS adds a number of features and possibilities.  The LCD displays the speed in MPH and time.  Screen real estate on the 16 by 2 LCD is very limited so this is all we could display.  The next version will contain a bigger LCD and include the date, direction, and even coordinates.  The GPS is very easy to connect.  The circuit diagram is below.

 

GPS Tutorial and Source Code

Instructions:

  1. Connect the yellow wire to port 6 on the Arduino.
  2. Connect the red wire to the 5V supply.
  3. Connect the black wire to ground.

Final Diagram:

 

Instructions:

  1. Put a 1K and a 10k resistor in series.
  2. Connect the positive side of the 10k to the 24V battery on the chair.
  3. Connect the negative terminal of the 1k resistor to the ground.
  4. Connect the negative terminal of the battery to ground.
  5. Connect a wire between the 1k and 10k resistor to A0.

 

 

Source Code:

 There are comments to give you an idea of what each section of the code is responsible for.

 

Cost Report:

Component

Qty

Unit Cost

Total Cost

Min Qty

PMB-648 GPS SiRF Internal Antenna

1

$39.99

$3999

100

1K ohm, 1/4 watt resistor

$.16

$16

100

10K ohm,1/4 watt resistor

1

$.20

$20

100

Parallax 2×16 Serial LCD (Backlit)

$26.99

$2699

100 

 Arduino Compatible UNO Rev3 Development Board

1

$14.99

$1499

100

Dual Stereo Potentiometer

1

$0.12

$19.37

100

TOTAL

 

$82.45

$8252.37

 

Reflection:

Measuring the voltage output of a battery is a great way to get an idea of its capacity, but it is far from precise.  This project will give an estimate of the mileage but does not take in account for the battery condition and the chair’s output.  It makes an assumption the battery is in good health and you are moving at the maximum speed on a flat surface.  In the future, we hope to refine our circuit by adding other factors, for example, the current to give a more accurate reading.  Currently, our equation only works on the wheelchair we tested.  Coming up with ways to generalize these equations to work with all models of wheelchairs and different types of batteries will be the end goal.

The LCD is another limitation.  Using a 16 by 2 LCD really limits what you can display to the customer at one time.  The plan is to add a larger touch screen to the project.  It will show a lot more information including options for different units of measurement and even allow for input from the user.  We are considering adding an SD card with map data so the GPS will actually place you on a map.

The battery meter began using an Attopilot current and voltage breakout to record our voltage.  The chip was fried for the second time, we switched to a simple voltage divider to use for the demonstration.  Since there have been multiple issues with the breakout, it will no longer be used in the future circuit.

This project was first developed on an Arduino Leonardo.  When connecting the GPS, nothing was ever sent to the Arduino.  After switching to the Arduino Uno, everything was working perfectly, so the Arduino Leonardo may not by fully compatible.