Archive for the 'II' Category
On The Fly – Team 12 – Progress Report II for Prototype II: Home Automation Framework

Goals for the week:

Per timeline: Be able to communicate with the (wireless communication) modules. Send basic Hello World messages back and forth.

Meeting times/dates

Meeting with John – Tuesday 8:20pm
Thu. Nov. 8 – 8 p.m. to 9:30 p.m.

Individual Hours:

Everyone: 3 hour meeting on Thursday

What we did:

We were able to make great progress with the wireless modules we had picked up in the past week. We used ribbon cables to attach Arduinos to two separate wireless communicators. We then loaded “server” code on one Arduino to listen for packets, and “client” code on the other to send packets every few seconds. We designed the server code to send power to a pin for one second whenever it receives a packet. We then connected this output pin to the relay/transistor setup we built last time, which made the relay click on and off (along with an LED “load”) whenever a packet was received from the client. This proved that the wireless communicators are actually capable of wirelessly communicating.

What we didn’t do:

We’ll be meeting with our business colleague next time to map out plans for the Dec. 8 open house. We’ll also continue to investigate building a case for the Raspberry Pi ensemble.

Where we are stuck:

No major issues at this point. Our next technical hurdle is using the ATtinys with the wireless modules rather than the Arduino.

Notes/Misc:

 
Team 9 – Progress Report II for Prototype II: Remote Piano Pedal

Goals for the week:

Make bracket for motor, potentiometer, frame, etc.

Meeting times/dates

Tuesday 9:00 am

Individual Hours:

Tom 6 hours, Design and build bracket

What we did:

A bracket was designed and built out of metal. The product seems to function as hoped. It holds the pieces in place firmly and provides a 1.5″ shaft to shaft distance between the motor shaft and the potentiometer shaft.

Tom spent several hours trying to figure out how to desing the hub and gears using CATIA but was unable to come up with anything usable.

What we didn’t do:

Tom spent several hours trying to figure out how to desing the hub and gears using CATIA but was unable to come up with anything usable. Also downloaded autocad and have spent some time trying to figure it out. Testing on the new h bridge chip .

Where we are stuck:

The hub can be fabricated in the metal shop on campus if a CATIA drawing can be made.

Notes/Misc:

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

Goals for the week:

  • Have a meeting with Tara to discuss how they want to control the LED lighting system remotely and start working on the remote control system.

What we did:

  •  Designed a circuit to control the LEDs as follow:

 

  • Tried to meet with Tara last week but because Tara was out of town, we rescheduled the meeting for this week

 

What we didn’t do:

  • Our plan to meet Tara last week did not happen instead we are going to meet her this week
Progress report II Team bravo squad (team7) emergency gps locator

 

Goals for the week:
 
Tanner has been working on the gsm this week. Now that we have the gsm our goal is to get text messaging abilities for it. 
 
Meeting times/dates
 
Monday 7:00pm to 8:00pm and Tuesday 7pm to 8:20pM
 
Individual Hours:
 
Tanner: 2 hours programming the arduino for the gsm shield and programming the gsm to recognize a sim card
 
Bryan: 30 minute talking to our business partner Sydney on what we need from a phone service provider. 
 
Sydney: 1 hour communicating with AT&T 
 
What we did:
Tanner successfully got the gsm shield to recognize a sim card. We can now focus on getting a text message sent from our gsm shield.
 
Sydney  talked with AT&T and was given several text message service plans from them.
 
What we didn’t do:
 
We did not get a sim card from a mobile service provider that is activated with a small amount of data. The big service providers do have a prepaid option for there sim cards, so most likely there would be a monthly fee if we went with
a popular service provider.
We did not get the gsm to run off of the arduino. The arduino does not supply enough current in order for the gsm to work at its full potential.  We will most likely have to have an external source just for the gsm to work properly.
 
Where we are stuck:
 
The only area we are stuck is in testing the device. We do not have a mobile power source to test the device outside, which is is key for our project. The gps has only been tested next to a window inside a building, we would like to test it out on a sidewalk or somewhere a wheelchair may get into trouble.
 
Notes/Misc:
Lucky 13 – Progress Report II for Prototype II: Battery Assisted Grabber

Goals for the week:

We plan to wrap up construction of our cut down version of the grabber tool this week so we can start adding on features such as the pressure sensors to help automate grabbing and dropping objects, pursuing alternate means of controlling the device such as a touch screen, and working towards a telescoping design. Also work on individual projects on our own time.

Meeting times/dates

11/7 Tuesday 5:30-9:00 – Met in the Senior Design Lab to continue fabrication of the grabber and picked up pressure sensors from Tom

11/9 Friday 5:30-6:30 – Met in Senior Design Lab to work on programming pressure sensors to sense amount of pressure being applied by the grabber on an object and to stop closing accordingly.

Individual Hours:

Jeremy Wherten – Milled out percision slits in the shaft of our new grabber on a home lathe. Learned Google SketchUp for use with the 3D printer.

Justin Hickey – Looked into the viability of using a touch screen as an interface for the grabber including downloading/learning the necessary libraries, designing a mock interface, and learning how to adjust the sensitivity of the touch screen.

Charles Swanson – Researched the possibility of using electro-magnets to power the telescoping effect of our grabber and brought his knowledge back to the group.

Clayton Skaggs – Explored how to calibrate the pressure sensor and worked on designing a program to halt the closing of the grabber when a certain pressure threshold is sensed by the pressure sensor. Also learned how to use the 3D Extrusion Printer.

What we did:

This week we all but finished the fabrication of the cut down grabber (This is not counting the new additions we’re looking to implement). We completed the new cut down linear actuator. All that remains is mounting a new motor and the design will be functional. We also discussed our progress on our individual projects listed above. Lastly we used the 3D extrusion printer to design a basic interface for the new grabber.

What we didn’t do:

Still have yet to mount the motor to our grabber.

Notes/Misc:

[JEL group] – Progress Report II for Prototype II: [Operation Mobility]

Goals for the week:

Get data and material for the thing at exploration place.

Get feedback from Josh.

Implement a threaded version of our wireless solution.

Meeting times/dates

Tuesday at  6 to 7 p.m. to discuss our presentation on December 8th

Saturday or Sunday to meet with Josh hopefully to get video of our device and anything else we need for December 8th

Individual Hours:

Jerret- 20 hours figuring out which encoding was used as well as programming

Erika- 5ish hours researching GPIO for python as well as linux audio drivers

Long- 4 to 6 hours tinkering (search for better power supplies for wired solution, etc)

What we did:

We discovered that the data sent by the switch is encoded with iso-8859-1 specification. Because of this we can now handle the data sent by the bluetooth device without jeopardizing the integrity of the data.

We finished  preliminary code (python) that fulfils the specifications of our wireless solution. The code consists of a client which connects to the bluetooth switch and a server which currently connects to a faux commboard. Individually these processes work and have no problems. Unfortunately when combined and run as a single process we run into a problem. We are able to connect to the blue tooth switch and once we try to connect to the faux commboard either the switch gets disconnected or the faux  commboard is reset by our device. We will attempt to implement our solution into separate threads that share the information sent by the bluetooth switch in a queue and see if this alleviates our problem.

We discovered that some bluetooth dongles manufactured as Cambridge Silicon Radio devices are prone to crashing operating systems and that they should be avoided. We have actually 2 or 3 of these dongles and have experienced this problem here is an hciconfig output for one of the dongles. We also have a Broadcomm dongle and we have not encountered any problems with it.  We have seen that as of October 2012 bluetooth shields for the Raspberry pi are being introduced and might be a good solution for this problem. We will have to wait and see.

What we didn’t do:

We did not get in contact with Josh to see what kind of experience he has had over the last week with our device.

Where we are stuck:

N/A

Out Of Time – Progress Report II for Prototype II: Thermoelectric Hydraulic Temperature Stabilization Module v0.2b

Goals for the week:

Are goal for this week is to make more progress on the development of the physical construction of our water cooling system.  The Arduino programming seems to be under control, and won’t involve much more testing when the final physical prototype is ready.

Meeting times/dates

Thursday and Monday night @ 7pm.

Individual Hours:

N/A

What we did:

We completed most of the custom water block construction.  Holes were drilled, and the almost finished product was taken by Joel to complete using the appropriate equipment.  Arduino code was tweaked, but nothing major was changed.

What we didn’t do:

We did not pick up the water circulation equipment (pipe & fittings) and haven’t tested the dual CPU power supply system.

Where we are stuck:

Finding more time to meet.

Notes/Misc:

Water circulation testing and adequate power supply are now our main focus.

Group 3 – Progress Report II for Prototype II: Battery Range Meter

Goals for the week:

  • Figure out why AttoPilot Voltage and Current Sense Breakout won’t measure amps
  • Ask other group about what GPS to use

Meeting times/dates

  • Wednesday at 4:00pm with John and Tom

What we did:

We met with Tom and John about why the current sensing wasn’t working on our chip.  After testing it we discovered that we didn’t have enough amp flowing through the device to get a measurement.  We need at least 1.5 amps for a reading to be possible.  This shouldn’t be a problem because the amp output on the chair is usually higher than that.  Our next step will be testing it on the chair to confirm.

What we didn’t do:

We still need to talk to the other group and order a GPS unit.  We are meeting tomorrow and we will give this an action item for someone in the group to take ownership of.

Where we are stuck:

Everything looks good now but we need to schedule more meetings in the future.

Shade Technologies – Progress Report II for Prototype II: Motorized Wheelchair Canopy

Goals for the Week

  • Solder appropriate wires to potentiometer and attach potentiometer to Prototype II base
  • Code Arduino to regulate motor speed to regulate speed of extension and retraction of canopy
  • Select and purchase water-resistant canopy fabric
  • Select and purchase power connector for motor

Meeting Times/Dates

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

Individual Hours

  • Jenice Duong soldered appropriate wires to potentiometer and attached potentiometer to Prototype II base, 1 hour
  • Taylor Russell coded Arduino to regulate speed of extension and retraction of canopy, 1 hour
  • Albert Ogenche and Shital Shrestha selected and purchased power connector for motor, 1 hour

What We Did

  • Soldered appropriate wires to potentiometer and attached potentiometer to Prototype II base
  • Coded Arduino to regulate motor speed to regulate speed of extension and retraction of canopy
  • Selected and purchased power connector for motor

What We Didn’t Do

  • Select and purchase water-resistance fabric for canopy

Where We are Stuck

  • Pros and cons of different canopy fabrics
  • Whether or not fabrics should be interchangable
Marz – Progress Report II for Prototype II: Campus App

Goals for the week:

Add intermediate menu for map module to choose which markers to display on the map. Create and complete classifieds module to allow users to view and submit classifieds submissions from different categories, similar to craigslist.

Finish layout design on Events, Courses, and Book Store modules

Meeting times/dates

Tuesday, 6:30-7:00

Individual Hours:

Zane Sumpter, created intermediate map menu, worked on classified module, 6 hours.

Adam Hemphill, working on layout designs and logics for Classes, Book Store, and Events modules, 4 hours.

Mason McCanless, found more building information, created outline for final tri-fold presentation board, 2 hours.

What we did:

Created an intermediate menu for the maps module so a user can select which type of map to view. Some sample categories I put up are plain Map, Course Buildings, Parking Lots, Activities, and Food. Each school will be able to customize which categories are displayed, and the markers in those categories.

Map menu that lets a user choose which markers to display on the map

Next I created the classifieds module which allows a user to choose which category they want to view posts in. There is also a link for a user to submit their own post. Each school will be able to customize the categories that are displayed.

Menu for a user to choose which category to view classified posts under

When a user clicks to create a post, they are asked to choose which category to post under.

A list of possible categories to post a classified ad in

Once the user selects the category, they can then enter the title and description for their ad. In the “for sale” category, an optional Cost field is displayed. This field can be turned on/off depending on the category. Each school can customize which category displays this field. All input is sanitized so that HTML cannot be displayed. There is no option yet to upload images, that will be done at a further date.

A filled out classified post that will be submitted to the “for sale” category

After clicking submit, the ad is automatically posted, and the user is redirected to the category page that they posted under. Their post will be at the top. The posts are broken up by the days they were posted. 100 posts are displayed at a time. There is a  ”Show next 100 posts” link that displays when there are more posts that aren’t currently displayed. That link is not showing up in the screenshot below because there is only 4 posts. If the user entered a cost for their post, it is displayed alongside the subject, otherwise it will not show up if the field was left empty.

A list of user submitted posts under the “for sale” category

When a user clicks one of the links to a post, they are taken to a page which displays the the full date, email, title, and description of the post. Their is also a button to allow a user to respond to the post by sending an email through the site to the user.

A sample classified ad

Clicking the “Reply to this post” button will take the user to a page where they can fill out an email to send to the submitted of the post. The subject is already filled in, and cannot be changed. The input is sanitized such that HTML will be displayed as text in the email. Clicking submit will automatically send an email out to the submitted of the post with the user’s email address set as the Reply-To field in the email.

A page to allow a user to contact the submitter of a post by email through the website.

What we didn’t do:

Still need to add a way for a user to edit/delete the classified posts that they have created.

-Still need administration sections for adding content to various modules.

-Still need to implement layouts and finalize designs for Events, Classes, Bookstore modules