We planned to use the I2C interface to serve as a means of communication for each candle. Two data lines are used: a clock line and and data line. These two line are shared with every device including the master and slave boards. The master board can request to write or read data to each slave board. The signal consists of multiple sets of two bytes of date. The first seven bits in the first byte is the address of the slave board that is being addressed. The last bit is signaling whether it is requesting for the following data to be written or read. The second byte is the data the master is trying send. If the slave successfully received the data bit then it will send an acknowledgment bit to the master board.
We ran in to difficulties trying to simultaneously interface with P and PB variant boards because they require different address name schemes.
For the Hardware portion of the prototype, we used a variety of objects.The largest of these was a standard bicycle that we used as a base for the odometer and the speedometer to sit upon. Next we used two breadboards to start, however this was later slimed to one breadboard to hold the wiring and transistors for the project. We also used an ATMEGA328P Xplained mini board to process the inputs and outputs we needed for the project. Miscellaneous electrical components include some resistors, wires, potentiometer, an LED display and a capacitor. The most unique component used would be the Hall effect sensor, which is in layman’s term a magnet sensor. As a magnetic field gets in range of the sensor, the total output voltage of the Hall effect will be changed due to the strength of said field.
The chosen task by Team 14 was to create a bicycle odometer & speedometer for use in everyday life. This would allow the hard working men and women of America to stop getting into accidents while calculating the velocity they are traveling with rate and distance. This could potentially save many lives and it is the honor of Team 14 to do this great work. Team 14 hoped that by creating this project, they would learn more about real world applications for the material learnt in the class. The project was performed by first creating the code for the odometer and speedometer, and next was the task of creating a stable mount for attaching the components to the bicycle itself. Lastly was field testing to guarantee it works. The equipment used by Team 14 for the project includes: A bicycle, an ATMEGA328P Xplained Mini, a Hall effect sensor, an LCD display, as well as a few miscellaneous electrical components such as resistors.
As for the technical components, the hardware was very similar to previous lab work in which we modified to obtain our project. For instance, the corresponding lab (#4) had the output be delivered to an LCD, which ours was adjusted to go to an external speakers. In addition, the major component was a “Guwoops” light sensor which helped to make the conversion.
From our project, the interesting thing about our code is how the output signals are converted into realistic musical notes. The original approach we were going to use the received signals as a corresponding output using a speakers. But, we actually decided to create a realistic version which takes in the signal and translates them into real-world musical notes; therefore that is the most interesting portion of our code. The above photo only portray the first few conversion because including more would just be repetitive. Also, all the code is a series of if statements which tells certain signals to convert to particular musical notes.
The proposed idea was to create a Theremin, an electronic musical instrument which is used with only gestures and no physical contact. The goal of the project was to successfully implement the idea while only using the knowledge from the previous lab work and creating a successful product. Therefore, the equipment necessary to complete the project was Atmel Studio and certain hardware components such as wiring, resistors, and amplifiers. As for the software aspect, the concepts of a previous lab were used to implement the proposed idea due to the similarities of the two. As a result of the effort into the project, the goal was accomplished as the Theremin was fully implemented. It was successful because of the way each gesture creates specific musical notes.
One interesting aspect of the code is the implementation of ray tracing. Ray tracing is basically casting a “ray” from a point outwards, gathering data about when the ray encounters an object, and using that data to interact with the surroundings. In this project, Ray tracing is used to find out where the visible walls will be. A ray is cast from the user’s current position, and when it encounters a wall in the maze, it instructs the program to activate the led at that position. It repeats this all the way around the user, until the entire view of the maze that the user would have while within the maze is constructed. This is referred to as the “frame” and is how the program decides which LEDs to have on after each move made by the user. This does result in a small delay between each move until the next frame is displayed, but also gets the desired result of only showing the parts of the maze wold be visible in the maze to a user.
We performed the project with the intent of applying some of what was learned throughout the semester. It was originally conceived with the idea of using a servo motor and sensors, at which point it was only a question of how to use them in a practical way. We decided on a carnival game (of sorts) that involves placing a ball on a rotating slide and aiming it toward an opening to a buzzer sensor/shock sensor combination. If the player hits the buzzer, a random number generator determines whether the buzzer goes off (win) or does nothing (loss). In other words, the game relies on a combination of skill and chance. In true carnival game fashion, the player gets three chances to to make the buzzer go off. We used two computers, two microcontrollers, two breadboards, a shock sensor, a passive buzzer, a servo motor, foam golf balls, and a variety of household items
One interesting thing about our design was that we were able to code the different angles we wanted the motor to turn. We had different cases based off user input that selected which angle to use. We then had a variable in each of those cases to store the degrees chosen, so that the return motor function would know how far to come back so that the catapult could be shot again.
As you can see in the image above, the red arrow is pointing to our motor, which is being used to pull back the catapult’s arm. The yellow arrow is pointing to our Atmega328PB which is sending out our signals to the solenoid and the Big Easy Driver. The blue arrow is pointing to the Big Easy Driver which is controlling the motor. The green arrow is pointing to the solenoid which is acting as the release mechanism. Below is the schematic to make it all work.