Archive for the 'Prototype II' Category
[Alpha Team] – Prototype II Final Report: [The Smart Mailbox]

Introduction:

The smart mailbox is intended to provide its user a feedback from inside his mailbox,  the user should not have to go every  day or every few hours to check if there is a new mail or not. The final product of the project should notify the user when a new mail comes through an e-mail. One more important extra function is that the final product also takes a clear colored picture from inside the mailbox and send it instantly with the e-mail, so that the user can take a closer look to his mail to decide if it’s a mail he is interested about or just junk mail.

We have built our project around a classic standard household mailbox; this mailbox will harbor one arduino unit running on power from a  mounted small solar panel that charge a rechargeable 6v battery to provide all necessary power for the whole unit.
This ardunio unit is connected to a cmos integrated camera and a switch that turn the unit on and off depending on every time the door of the mailbox is opened and a new mail is inserted inside.

The integrated camera takes pictures while an attached 2 bright LEDs are turned on to light inside the mailbox.

After that, a stream of wireless information is transferred to the house arduino unit that receive such signal that notify about a new mail and the picture from inside the mailbox. This arduino unit is connected to an Ethernet unit that connect to the internet and send an e-mail to user with the notification and the picture.

Description:

We first had to make the  2 arduino units be able to communicate wirlessley , we did that through the Xbee shields , one for each unit. We then programmed the units with C sketches that makes us use the Xbee through  regular pin instead of the serial port.
We made a lever switch on the “always off”  position and attached it to the door of the mailbox, when the door is opened then the switch send “on” signal that is received by the arduino in the mailbox, then the arduino tells the camera to take a picture while turning the 2 leds on . Then switch the camera and leds off and send a signal wirelessly to the in-house arduino unit that read the information and send them as an e-mail to user with the picture. After that, the arduino unit in the mailbox is reset and go into the sleeping mode. The arduino unit in the house is always fed by power from the grid, while the unit in the mailbox is fed by the 6v rechargeable battery that get power from the small solar panel on the top of the mailbox.

[Pictures/Code to be added]

Diagrams:

[diagrams place holder]

Reflection:

The project worked better than we anticipated, thanks to the great flexibility of arduino, we have succeeded to make the two arduino units communicate successfully, the switching fit has worked too and made good switching for the whole unit in the mailbox. The camera was not difficult to be programmed; however we still work to make it go into sleep mode when not in need. We have succeeded to send pictures from the arduino in the mailbox to the one in the house. The Ethernet unit was more difficult than we expected to work and function, good reasons are that it need many parameters that are not easy to be found like the ip of the mail server for the user. However we managed to make it work and send e-mail notifications to very specific users that we already know the ip of their e-mail servers.

We still need to make the Ethernet unit work in a way that makes it much more user-friendly and work more on making the whole mailbox unit go into sleep mode when not in use to save power and battery life.


Gryffindor – Prototype II Final Report: Cyclemetrics

Introduction:

In the past months, we have been working to create bicycle computer.  Its function is to provide cyclists relevant information to improve their performance by measuring and calculating forces, power output, velocity, and acceleration. In order to calculate the forces output onto the bicycle, we used a strain gauge that detected the amount of pressure that was being put on the idler. We used a Wheatstone Bridge with a potentiometer to measure the change in resistance of the strain gauge, and then used a differential amplifier to make the output voltage usable by a microcontroller. To output this data a dot matrix LCD display along with a Arduino microcontroller is used to display all the data the cyclist needs.  By creating and fabricating boards using the Eagle program we have been able to minimize space needed in order to fit our devices onto the bicycle.  For wireless communication we have used a zigbee device to help collect data and dump the information onto a sd card in order the analyze data further.  –more will be added

(Give a brief description of what you are trying to solve. Include a high-level overview of what you made, why you made it, what parts you used, and what it does.)

Description:

We have created PCB boards for our wireless sensor and hall effect sensor using the CAD software Eagle.  By using a method called photolithography, we were able to produce small-sized boards to solder our sensors, resistors, and other parts onto. We also attached a strain gauge to the idler that would detect any forces being applied to the bicycle by changing its resistance when it was under compression or tension.

Code can be found here: http://ee585.dyndns.org/browser/EE585/trunk/code/wireless

Reflection:

For our project we are still having issues with the hall effect sensor, but plan to have it working before presentations.  The wireless code was difficult, but is working at the moment.  We also created code to dump all the information gathered and dump it onto a sd card for further evaluation.  What has worked quite well is the creation of the pcb boards using photolithography and Eagle CAD software.  All we have left to do is putting everything together and making sure it all works out well. 

The Mind Takers – Prototype II Final Report: RC Mind Control

Click here for The Mind Taker’s Prototype II Final Report!

Team GTLE – Prototype II Final Report: RF Signal Enhancer

 

Our RF Signal enhancer works on the basic concept that a readout from a certain measurement will be transported wirelessly to another location, and again transported back to a central location from that second location. In order to accomplish this task, we are utilizing a street lamp because it already has the known operating values (operating current, open circuit current, short circuit current). Based on these operating values, we are taking measurements off of the input cable to the ballast. Depending on the measurements taken, there are three currents that we are interested in. The first is if the current is zero. In this case, it is known lamp is not operating properly, or in other words, the ballast is not pulling any amperage. Therefore, we can come to the conclusion that the ballast is bad, and can be replaced. The second is the full operating current. This current will tell us that both the lamp and the ballast are operating fine and there is nothing wrong. The third is the open circuit amperage, which is an indication that the ballast is working fine, but the lamp is out. The measurements we take are being displayed by a LCD screen right now. The next step is to take these measurements and send them to a location further away wirelessly, and then send them again to a central location so that an operator will know what to do.

Description:
We started with 150 watt, high pressure sodium street lamp. The components of this street lamp (the lamp, igniter, ballast, and capacitor) were laid out on a board and connected so that their individual components could be easily seen and manipulated. These components were connected to a termination board, which runs to a 120V AC input. The reason for the termination board was so that a power supply could be connected in order to power the arduino off the same system. This power supply for the arduino takes a 120V AC in and converts it to a 12V DC out. Originally, the problem with this supply was the fact that it still had noise and the fact that the arduino, with a load, will start to burn up if given this much voltage. The first solution to this was to build our own power supply that would take a 120V AC in and convert it to a 5V DC out. However, the components needed to build this power supply had to be rated at such a high voltage that it became difficult to find them. So, instead of building our own, we just modified the power supply previously used and put a voltage regulator in series with it. This allowed a 5V DC out that had little noise to become the Vin for our arduino.

After this modification was made, the arduino ran as expected without getting hot. We also created a code for the arduino to work with a CT to get our measurements from the input cable to our ballast. The CT that was used was a current transformer that when reading a one amp output, it will give a one milliamp ouput. Knowing this, we connected this output to a resistor which allowed us to get a voltage output that was readable by the arduino. Initially, when the arduino was still connected to the computer, our readouts were fine. They were not what was specified on the ballast, but this is not our concern. As long as we are getting three different readouts (0,operating, and open circuit), this is good enough for our project. However, once the arduino was loaded with the code but not connected to the computer, it was giving a steady voltage output whether in operating conditions or short circuit. This provided a problem that needed to be solved.

Upon further investigation and testing, we realized that the issue was related to the breadboard. Due to some glitch, when connecting the Current Transformer sensor output wires to the breadboard and then connecting a 560ohm burden resistor in parallel with it which in turn was in parallel with the input wires to the arduino A0 pin and ground, the readings would be off. The fix, bypass the breadboard all together so we wired the resistor directly in parallel onto the sensor wires and then into the arduino. This resolved the issue and the values we are getting are as follows depending on the input power supply are: (note: this values are approximations)
Lamp start up: 2V but this will dip down to about 1.7V while the lamp is arching
Operational voltage: 1.8V
Open circuit voltage: 3.0V

Diagrams:

^^This was the original circuit diagram for the power supply (courtesy of Shawn Westervelt) that was going to be used to reduce the voltage going into the arduino, but was later scrapped for a simple voltage regulator.

^^Eventually, this regulator was hooked in series with the original power supply for a 5V input to the arduino that had less noise.

^^Circuit diagram of arduino/board set up.

^^Schematic view of the arduino/lcd set up

Reflection:

The most successful part of our project was the street lamp setup. The parts we acquired were all in working condition and the setup was fairly straight forward. The surface we mounted everything onto (part of a printer) was an ingenious find from the garage. One man’s trash is another man’s treasure! Just about every other aspect of the project, at least after the first initial attempt. We had problems ranging from hooking up an LCD screen to our Arduino, to waiting the better part of 2 weeks for a sensor to come in the mail from China, only to find that it didn’t come with any sort of paperwork or directions. The biggest problem by far was writing our Arduino code, that measures the current and displays values on the LCD, and troubleshooting various issues with it.

If given a do-over, we may have gone with a different sensor than the one currently being utilized. We have since come across a current sensor that will measure current and convert it to a voltage, which would have saved us the trouble of incorporating a shunt resistor. As of now, we have made no decisions on whether to pursue the second sensor as a future option. There may be a more efficient, more cost-effective micro-controller out there to be utilized, but our project progression has yet to reach the stream-lining phase where tinkering with efficiency would be the main focus. The goal right now is to successfully prove that our original design ideas are capable of doing what we planned. Overall, we still view our problem-solving path as really the only option to go about solving our project’s problem.

[Team Haymar-Phuong-Giang] – Prototype II Final Report: [Motion controlled RC car]

 

Introduction:

Innovation and imitation is without a doubt the best form of flattery. Our team witnessed many type of motion sensor toys and electronic gadgets. Consumer products such as the cellular phone, gaming consoles, and electronic toys are prime examples of products that have incorporated the motion sensor technology into its usage. We brainstormed and combined all the bells and whistles of one platform with another. What we arrived at is a motion controlled RC car. We wanted a gadget that will actually be marketable; yet, at the same time be fun and catchy. We’ve all experienced the high tech motion controller of the Nintendo Wii console, but the feeling of throwing a virtual bowling ball gets boring after a few games. We have also raced our RC in the streets against the neighbor’s kid to see who’s car is faster; however, the simple controller layout of pushing a joystick to accelerate and turn becomes lackluster after a while. Our team built a motion sensor controller to control an RC car to keep players on their toes. The amount of concentration in timing a turn with a motion of a wave while accelerating brings more physical activity into playing with an RC car. We used accelerometers as motion sensors to detect the direction of the hand movements. The arduino reads the output of the accelerometer and sends the data via xbee to the receiving xbee on the car and the arduino on the car will control the motor according to the program. The project’s items list consist of typical parts found in a DIY electronic project: capicitors, breadboard, micro controller(arduino), xbee communicator, wires, diodes, an RC car, and various computer applications.

Description:


Our team continued on our prototype I project. Our prototype I featured a rewired RC car
and re-configured controller . With our prototype II, we wanted to expand on our controller by incorporating the motion sensor, the accelerometer. We programmed the accelerometer to work with micro-controller.  We also have a working prototype glove which acts a controller. The glove holds the accelerometer and the micro-controller.

Diagrams:

Our circuit diagram remains the same from prototype I.Prototype II test

Reflection:

Our team’s project prototype II turned out very decent. We ran into a lot of programming hurdles. If we were to re-do this project, we would probably outsource the coding. Our next goal for the project would definitely be speed control and a refined design of the controller.

Team Name – Prototype II Final Report: DoorTextChecker


Introduction and Description:

What we built was a deadbolt that could be controlled via a text message.
This was part of our overall idea that someone could control a door or 
garage door from their phone and monitor if they were opened or closed.
So this deadbolt can be controlled by a motor to open and close by a text
message and allow the user to know what happened.The way it was built was
a stepper motor was mounted to a deadbolt.The stepper motor was wired to 
an arduino uno and the arduino recieved messages from a java program.
The way the motor was mounted was that the teeth were grinded down to 
fit into the mechanism that worked the lock.

The arduino would recieve an integer from thejava program indicating what 
action the user wanted then would perform the action and send back the 
results of its action - fail/success or open/closedback to the java 
program that would inform the user.The communication was handled using 
the com port to communicate between the java program and the arduino 
board, to send an integer in java to an arduino board it needs to be
masked because java send information in UTF-8. Then it can be casted back
to an integer on the arduino. From there it is setting pins high and low
based on which direction thebolt needed to turn or check if the door was
opened or closed.
The java program consisted of using the swing library to build a graphic
user interface, the javamail api and a modified version of the java serial
class from http://www.arduino.cc/playground/Interfacing/Java
(note:the modified class will be posted.).The java mail api sends and
receives messages and the serial class sends info the the arduino and 
receives it. Threading through swingworker isused to ensure that every 
request is handled.Also it saves user settings to a file.It also has
multiple windows, and a pony and buttons.
tl;dr:
The java program monitors an email account for a command, once it is
received it sends a message to the arduino, arduino does said task,moving
the deadbolt, andgives the java program a message to give to the texter.
Arduino sketch:
Deadbolt
Java code, must compile all files at once:
TSLSend
TextCheck
SerialTest
PrefDialog
MainWin
GmailFetch

 

 

Diagrams and Pictures:

The first picture is the diagram supplied is the ic chip hookup to the arduino and output 1,2,3,4 go to input pins 8,9,10,11, the rest of the pictures show the setup.

 

Reflection:

It is nice that everything worked for the most part as expected in a sense
we made a few coding changes to make stuff work better on the
communication end like we had originally planned to have. It was
originally planned to have it send a sting stating what needed to be done
but it was decided to just switch to integers to specify what commands are
being sent to the boardThe other thing that didn't work right now was the
motors available aren't strong enoughto turn the motor so we will have to 
order a stronger motor to turn the bolt, that is the only problem we
really had. We don't think there was a better way to do this program.
Using java as the language is perferable because it allows any os that
supports java to run the program.The only real downside to it is that
oracle doesn't support serial anymore withjava so there isn't as much
support out there for it. Other than that we can'tthink of anything else
we would have done differently and even with the inconvenience java
provides it is still the way we would have done this project. How we
would expand our project in the future would be to be able to manage 
multiple items at once. As we have it now it has either been a garage
door or a deadbolt. To accomplish this we would need everything to be set
up wirelessly possibly by using xbees to accomplish this.  Another item
that would like tobe looked into would be to also avoid reliance on
needing a computer on all of the time.To accomplish this we would need to
set up a server on an arduino that could thencommunicate with other
arduinos and we would like to build an app on aphone that could
communicate with the server.  Also what would like to be addedwould
be something that could monitor if something was turned on or not, like a
space heater that way if it is on it can be turned off remotely. 
Also it was mentioned that this could act like a security system so we
would like to add something that could monitor if a window was broken or
something to that effect. 
So to summarize what we would like to do next-
a.)Control multiple components not just one at once.
b.)Set up a server to control the multiple components and have a phone
   app that can control them
c.)Set up a way to monitor outlets and windows


Samov – Prototype II Final Report: Interactive Projector

Introduction:

We are trying to create a projected screen that has a touch interface. It originally was planned to be controlled by reflection of infrared LEDs off of a finger tip. The infrared light is then seen by a Wii remote which our software (Smoothboard V2) outputs to the screen.

Description:

Using an Infrared (IR) LED array and the infrared camera in a Wii remote, an IR point or blob was tracked. The application maps this IR blob to the computer and is used as a substitute for a mouse. The Wii remote is connected to the computer via a Bluetooth connection. A projector is used to project the screen onto a surface such as a wall, and the Infrared LED array is used to calibrate the screen as well as interact with the screen.
Infrared LED Matrix:

Diagrams:

Schematic of Infrared LED Matrix:

 

Reflection:

We had trouble getting many of the pieces to work and come together and had to make many approach changes along the course of developing the prototype. When using an infrared laser as the source of infrared light it did not reflect back into the Wii remote camera as expected. Also, when using the IR LED Matrix the infrared light did not reflect back either, so we ended up having to use the direct infrared source. The Wii remote had problems connecting and staying connected to a computer.  We would have done something different from the start that involves more construction than coding. If we had the expertise, we would write the whole code from scratch instead of using modified code. If we were to continue this project, next, we would figure out a way to make it work off of reflected infrared source instead of using the direct infrared source.


[Team Omega] – Prototype II Final Report: [Washing Machine Auto-Balancer]

Introduction:

Our device will automatically correct balance offsets inherent in clothes filled washing machines. Specifically, the balancing aspect will come into effect during the machine’s spin cycle. We will use an assortment of micro-controllers, accelerometers, solenoids, rotary transformer, and a ballast. The market for this type of idea includes the whole of appliance purchasing people. Specifically though, this probably would be an option on mid to high-end machines, as the addition of these parts add cost to the overall machine.

Description:

For our prototype, we coordinated the programming and interfacing of the micro-controllers and 3 accelerometers to determine center-of-mass in a rotating body.We mounted the accelerometers to the boards and tested it with the attached code. Code

To verify corroboration on the soldered accelerometers, we used this code Verification
The output that we got:

Horizontal
0 500
1 503
2 501

rotate 90 deg
0 506
1 509
2 506

rotate -90 deg
0 494
1 497
2 495

By inspecting these results we have come to three important conclusions:
1) The troubled soldering process had little or no negative affects on the accelerometers
2) The readings corroborate vary closely
3) The accelerometers have approximately the same reaction to the same force

The third point is the most important. This means that, though the sensors have different offsets, their reactions are the same.

Pictorial Description

Diagrams:

The schematic for the Drum electronics

Schematic

Reflection:

Based on the outputs, we consider our main goal for this prototype to be achieved and feel like we are moving in the right direction for the final project. The only major issue we faced while working on this, was getting the parts and soldering them properly. Tom was a great deal of help in correcting these soldering issues.  There is nothing we would’ve done differently, provided we had an opportunity.  

Water is an issue we anticipate might challenge us later on. Initially, the challenge will be keeping the water in the ballasts while in operation. This is a challenge since we’ll be employing a passive system of water retainment. Our current approach will be to use channels to divide the water into manageable portions. Subsequently, once the water is kept in place, the next problem will be removal. At present, the idea is to slow the speed of the machine to a point that facilitates a passive dumping of water from the aforementioned channels.