Archive for the 'III' Category
Progress Report III Prototype I Assignment

Third Progress Reports for Prototype I go here.

Progress report III JEL group

Goals for the week:

Buy Raspberry pi

Learn to use linux tools to obtain Bluetooth device information as quickly as possible so Josh does not have to go too long without his devices.

Begin Trying out some bluetooth coding in python.

Meeting times/dates

Tuesday October 2 from 7 to 8 in the Engineering building

Saturday October 6 Noon to 2 at Linquist study room. then 2 to 3:30 at CPRF with Greg Carpenter.

Individual Hours:

Jerret -20 to 30 mainly learning how to use linux tools such as hcidump, hcitool, hciconfig, sdptool and spooftooph to obtain bluetooth device MAC addresses, clock offsets, class types and provided services by certain bluetooth devices and what port those devices are located at. As well as reading about and attempting bluetooth socket programming using the Python programming language and the Bluez bluetooth stack.

Eirka – 5, learning about bluetooth programming in python. Also learning about micro controller interrupts and how they will be useful for us when interfacing with The communication board.

Long – 5, studying about alternative ideas such as a multi level switch as well as getting our old communication board powered on.

What we did:

We put in an order for a Raspberry pi (should arrive 10/09/2012). The Pi has 2 usb inputs, and HDMI out, an audio out, a CPU and GPU,256 MB of Ram and other things.

We Met with Greg Carpenter at the CPRF and asked him some fundamental questions that have been bothering us for awhile. We learned that when Josh engages the reverse and forward switch of his chair (which is can do with 90 percent accuracy) the chair ignores these contradictory commands and nothing is done. We can use these unused inputs in our relay as the triggers from ‘Drive’ mode as Greg Calls it to “Com” mode. How we were going to accomplish this mode switch had been bothering us for some time but now we have the answer and can proceed forward.

We obtained a functioning but batteryless (old) Com Board. We will attempt to power it on and obtain a better understanding of how the single switch UI works.

We also obtained a non-contact switch similar to the one Josh uses and will attempt to figure out how to split the cable in such a way as the original output is maintained while a new output going to our relay will be capture. We will use this output for our mode switch triggers.   

Most importantly we developed a better idea of the practical ways that Josh must uses his devices from day to day.

What we didn’t do:

We didn’t get to meet with Josh due to an illness. Because of this we were not able to obtain any information on his equipment (bluetooth switch, Communication board) or how he used it.   We were able to determine from Greg that activating forward and reverse is possible with the current equipment co better

Where we are stuck:

We must wait for delivery of the raspberry pi.

Notes/Misc:

We think this is totally doable!

Team 9 – Progress Report III for Prototype I: Remote Piano Pedal Controller

Goals for the week:

Work on coding, research motors, transistors

Meeting times/dates

Tuesday morning at 9:00 am Tuesday evening at 6:30

Individual Hours:

Tom: 2 hours met with Tom and worked in the lab

Atul: 2 hours on the arduino programming, Arduino voltage output variations with respect to the accelerometer

What we did:

Arduino Motors that are on hand are too slow for project but will work for prototype. Auto door lock motor might be an alternative. Tested Arduino voltage variations. Tried to setup H-Bridge motor drive for required motor action.

What we didn’t do:

Concept test survey. Meet with piano players, measure pedal tensions.

Where we are stuck:

Fill this out by Monday eve: Logistical or technical questions could go here. Anything you want to remember to ask me when we meet might go here too.

Notes/Misc:

Marz – Progress Report III for Prototype I: Campus App

Goals for the week:

  • Get android app up and connecting to the site
  • Setup database and have a few sample schools to select from
  • Setup javascript menu to be loaded on each page, rather than a separate page
  • Figure out how to incorporate building information into the app

Meeting times/dates

No meeting for the week. Figured out what we needed to do for the week in last week’s meeting.

Individual Hours:

Zane Sumpter – 3 hours setting up database and creating javascript menu

Mason McCanless – 1 hour – Explored the available building information on WSU’s website. Brainstormed ideas on how to incorporate the building info/groups/events into the app/website.

Adam Hemphill – 2 hours – Research on HTML, javascript, php. Thoughts on building info interface.

What we did:

Setup the database and added a few sample entries for various schools. Created an index page to list the sample schools. Modified the maps page to read the school data from an id passed in the URL. Created a javascript menu that can be quickly displayed on each page rather than slow loading a separate menu page.

Index page that displays the sample schools loaded in the database.

 

Back to menu button displayed at the top of each page that will load the javascript menu without any load time.

 

Map that is instantly loaded when clicking the back to menu button

 

id that is passed around in the URL that is looked up in the database to select the rows for the appropriate school

Brainstormed ideas on how to incorporate the building info/groups/events into the app/website. Looked through wichita.edu for ideas on what information to add and in what format. Google map on wichita.edu can be found here:

http://www.wichita.edu/thisis/buildingtour/googlemap.asp

Clicking on a building and clicking “Read More” takes the user to a page on wsu’s website that displays building info as well as events and other links for what goes on inside the building.

What we didn’t do:

Get android app interfacing with marz.yzi.me

Write up building info scripts for the website

Group 3 – Progress Report III for Prototype I: Battery Range Meter

Goals for the week:

  • Come up with new idea
  • Figure out how to test a battery accurately
  • Order volt and amp meter
  • Order LCD
  • Measure data from wheelchair in field

Meeting times/dates

  • Tuesday 6:00 PM – 7:30 PM
  • Thursday 6:00 PM – 8:00 PM
  • Sunday 1:30 PM – 4:00 PM (Todd unable to attend)

Individual Hours:

  • Todd – 5 hours
  • Merl – 6 Hours
  • Mido – 6 Hours
  • Saed – 7 Hours

What we did:

In the Tuesday meeting we settled on a new idea to create a range meter that will display how far the wheelchair can go on a remaining charge.  This was an idea that was brought up at the first CPRF meeting and something that Greg Carpenter thinks would be a great idea.  The prototype will be accurate measurement of a battery that we can use to create a formula for the distance.

In the Thursday meeting we did research to see how we can accurately measure a battery and get the remaining capacity.  We decided on meeting Sunday and taking amp and volt measurements from the wheelchair while we ran down the battery in order to collect data.

Todd read a post in an arduino forum about a guy that did a similar project to accurately measure the remaining battery in his boat house battery.  He e-mailed the guy directly to see if he would be willing to share some of the information about the project.  Still waiting for a response.

Mido tried to see if the track at WSU was available on the weekends so we can use to measure the distance the chair travels.  You have to pay to use the track on the weekend so we did not meet there.

On Sunday, Mido, Merl, and Saed met to get measurements on the wheelchair.  The wheelchair had batteries running in series with each supplying 75 amp-hours.  The voltage reading stayed around 25.2V so they were unable to see a change as the battery drained.  The amp output changed too often to measure accurately as well.  On a really flat surface at lowest setting it read around 1.63 amps, but that changed rapidly with any alteration to conditions.  Getting data by hand will not be accurate enough for this project.  Another way to measure is needed.

Saed spoke with instructors about this issue.  They said the best way to figure out the battery is to do measurements at certain intervals and get the amp-hours that the batteries are outputting.  This will be the best way to get the most accurate measurements.  They also said not to worry about temperature because that will make the system too complex.  Just account for a certain error percentage.

Saed has a device that he can borrow from work and we will meet again to retest.

Links to research:

What we didn’t do:

We were unable to get accurate data to predict the capacity of a battery.

Notes/Misc:

Greg gave us these links for things to order that might help.

https://www.sparkfun.com/products/9028
https://www.sparkfun.com/products/9418
https://www.sparkfun.com/products/10216
https://www.sparkfun.com/products/10915

We have ordered the volt and amp meter.

Infinite Loop – Progress Report III for Prototype I: Hazardous Weather Warning System

Goals for the week:

  • Hack high powered RGB LED controller system
  • Modify the Arduino circuit to control the LED through a MOSFET or similar device
  • Modify our circuit to receive button input

Meeting times/dates

  • Monday 7:00pm – 9: 00pm
  • Tuesday 7:00pm – 9: 00pm
  • Saturday 9:00am – 11:00am (as required)

What we did:

We successfully created the Arduino controller circuit based on the following schematic

This circuit varies the signal feeding the LED to create different colors. Ultimately this will be used in our circuit to provide different colors of warning lights for the residents of the CPRF.

We also ordered a 50W RGB LED for testing, which should arrive sometime this week.

We found several links that are quite useful to our project. Below is a sample video giving an idea of how our prototype should function.

below is a sample of the code we can use to control the leds after we decide on the scheme:

INFINITE LOOP

What we didn’t do:

Eventually we’ll need to read a data stream from a weather radio, we need to begin researching this so we can adapt it into prototype two.

Shade Technologies – Progress Report III for Prototype I: Motorized Wheelchair Canopy

Goals for the Week

  • Solder input sockets onto Arduino Uno
  • Attach metal arcs onto prototype base

Meeting Times/Dates

  • 6:30PM-9:00PM, Monday in EECS Sr Design Lab

Individual Hours

  • Jenice Duong will solder input sockets onto Arduino Uno, 2 hours
  • Taylor Russell, Albert Ogenche, and Shital Shrestha will work on attaching metal arcs onto prototype base, 3 hours

What We Did

  • Soldered input sockets onto Arduino Uno
  • Attached metal arcs onto prototype base

What We Did Not Do

  • N/A

Where We are Stuck

  1. Is there a better way to attach metal arcs to prototype base other than duct tape? (Need to learn how to cut a wheel with a hole for flattened shaft motor.)
Out of Time – Progress Report III for Prototype I: Hot/Cold Pad

Goals for the week:

  • Get everything wired up.
  • Test all the purchased items.
  • Test cooling capabilities of peltier.

Meeting times/dates

Thursday:N/A  , Monday 7:00 p.m.

Individual Hours:

Joel : Research. Looked for suitable copper sheet to use.

Ralph : Dream about finished product design – 56hrs

Hammad :

Samuel :

What we did:

- Met with John and Tom to get a basic wiring design.

- More arduino research. (here)

- Started wiring circuit together. Soldered the relay, switch, and peltier up and tested the circuit using the DC Power Supply in the lab. Incorporated a kill switch also. Started the test at 6.0V just in case. Got immediate results showing when the relay was below 6V the relay won’t switch and the peltier gets extremely hot.

- Wired and tested the CPU cooling unit we purchased to make sure it would work for our intended purposes. Had to whack it for it to work but it eventually did. Also tested the fan that joins with it, works fine.

What we didn’t do:

- Finish prototype I

- Get arduino program running.

Where we are stuck:

- Finding more meeting times.  Class/Work schedules are conflicting.

Notes/Misc:

       

Team 12 – Progress Report III for Prototype I: Home Automation Framework

Goals for the week:

Build an interface between the remote control and the Raspberry Pi

Meeting times/dates

Google+ Hangout: Thursday 8pm

Working Meeting: Sunday 4pm

Individual Hours:

All: Google+ Progress meeting->20min

Working Meeting: 3 hours

What we did:

On Thursday, we laid out the plans to work on an interface for the remote control and write the code on Sunday.

On Sunday, we soldered cables from the Remote control into the Raspberry Pi’s GPIO pins. We wanted to use some Female to Male cables, but we couldn’t find any in the arduino kits or in Radioshack, so we soldered them on. We worked on the code running in the Raspberry Pi, and managed to write a program to turn AC outlets on or off from the Raspberry Pi. And then we all cheered.

We also begun working on an Arduino module for shutting blinds open or closed. Jose has the kit right now, and will be working on that next week.

What we didn’t do:

Interface the php server so that the WebApp can activate the python program.

Where we are stuck:

The DIY tutorial Jose found for the blinds has a bit greater scope than we are intending. It has more components than we need, so he will be sorting out which parts to skip and which to include, like light sensors and schedules, so that we may have a working model for the first prototype, and add the other stuff later. We also need a way to interface the RPi with it. We’re thinking Bluetooth.

We still haven’t agreed on a name.

Notes/Misc:

Dr. Zaman has expressed interest in helping Jose advance further in his Microcontroller class. He offered to extend his lab and some tutoring in a project he might think of. We don’t really know how to take advantage of this yet, or if it could tie in with the project, but it’s a thought.

Lucky 13 – Progress Report III for Prototype I: Battery Assisted Grabber

Goals for the week:

Continue fabricating new grabber design in the shop. Once again, the focus of this prototype is to refine the mechanics of motorizing the opening/closing of the claw at the end of the grabber.

Meeting times/dates

(10/2) Tuesday  5:00-10:00 -Spent time in the senior design lab continuing fabrication of the new grabber design.

(10/2) Friday 8:30-9:00 – Clayton and Justin met up for a quick tutorial on programming an arduino.

Individual Hours:

Jeremy Wharton -

Justin Hickey -

Charles Swanson -

Clayton Skaggs -

What we did:

This week we decided to tweek our design a bit. We decided step away from using a motor to spool up a cable to close the claw, we decided to attempt using a threaded shaft hooked to the motor with the other end screwed into a coupler connected the claw at the end of the grabber. As the motor turns it rotates the threaded shaft causing it to either screw further into or out of the coupler causing it to either pull the claw open or push the claw closed respectively. In that respect we spent our time in the lab Tuesday using the lathe to create a coupler to mount the threaded shaft to the motor, mount a premade coupler to the claw, and bring all the peices together for a quick proof of concept test.

What we didn’t do:

We have yet to properly mount the motor to the fabricated grabber.

Where we are stuck:

Build time is proving to take a large amount of time with this prototype, and more than likely the others to follow.

Notes/Misc: