61
edits
No edit summary |
(Text about coding stuff) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 20: | Line 20: | ||
===Embedded systems development === | ===Embedded systems development === | ||
During our project, we used Visual Studio Code and Arduino to program and control motors based on sensor data. Our first challenge was to determine how the motor should move. We aimed to ensure that the motors moved only once per activation, producing a single tone. To achieve this, | During our project, we used Visual Studio Code and Arduino to program and control motors based on sensor data. Our first challenge was to determine how the motor should move. We aimed to ensure that the motors moved only once per activation, producing a single tone. To achieve this, I created an initial test code to establish how to instruct the motor to move right when it was on the left and vice versa. | ||
Next, we needed to develop a pattern to simulate incoming sensor data. The second test code introduced random numbers to help us | Next, we needed to develop a pattern to simulate incoming sensor data. The second test code introduced random numbers to help us simulate a trigger value for the motors. This was combined with our previous motor movement code to create a preliminary response system. | ||
I then worked on enabling two motors to move independently. To accomplish this, I implemented two different random numbers so that each motor would move at a different "trigger value". Adjustments were made to delay times to introduce a more natural, randomized effect. | |||
To acquire real sensor data, we opted for an MQ-2 gas sensor, which detects combustible gases. We initially attempted to retrieve analog output values from one sensor. Since the raw sensor data wasn’t as representative as we needed, | To acquire real sensor data, we opted for an MQ-2 gas sensor, which detects combustible gases. We initially attempted to retrieve analog output values from one sensor. Since the raw sensor data wasn’t as representative as we needed, I decided to convert the readings into ppm (parts per million) for more meaningful analysis. | ||
The next step was to replace our previously used random numbers with actual gas concentration values measured by the sensor. | The next step was to replace our previously used random numbers with actual gas concentration values measured by the sensor. I then expanded the system to incorporate six sensors and six motors, which required multiple iterations to perfect. A major challenge was implementing all sensor values, motors, and their corresponding variables into a function that allowed each sensor-motor pair to operate independently. We replaced the general delay time in the loop with millis() to enhance achieve that. | ||
[[File:SG90 9g Micro Servo.jpg|thumb|273x273px]] | [[File:SG90 9g Micro Servo.jpg|thumb|273x273px]] | ||
After measuring the gas concentrations produced by plants over time, | After measuring the gas concentrations produced by plants over time, I made several adjustments to optimize the installation. Each motor was assigned an individual trigger value based on the gas readings from its respective sensor. Since sensor readings were taken at short intervals and did not fluctuate significantly, motors would have been triggered too frequently, leading to excessive noise. To mitigate this, I introduced individual delay times for each motor before they could be triggered again. To create a more natural and less predictable sound pattern, I introduced a "random factor". The motor's delay time was then multiplied by this factor which was recalculated with each sensor reading, ensuring a more varied and pleasant auditory experience. | ||
Debugging print commands were added to the code to help monitor sensor functionality when connected to a computer. These were primarily for troubleshooting and not necessary for the final public installation. Although the code could have been optimized for brevity, | Debugging print commands were added to the code to help monitor sensor functionality when connected to a computer. These were primarily for troubleshooting and not necessary for the final public installation. Although the code could have been optimized for brevity, I chose to keep it more detailed to maintain a clear overview of all sensors, motors, and timing adjustments. In the end, our system successfully produced tones in a random frequency, creating a dynamic and immersive experience. | ||
=== Technology === | === Technology === | ||
* ESP32 | * ESP32 | ||
* | * MQ-2 sensor for combustible gas | ||
* SG90 9g Micro Servo | * SG90 9g Micro Servo | ||
<gallery mode="packed"> | <gallery mode="packed"> | ||
| Line 228: | Line 228: | ||
==Manual construction == | ==Manual construction == | ||
[[File:Construction plan for the motor mount.jpg|thumb| | [[File:Construction plan for the motor mount.jpg|thumb|340x340px]] | ||
I was responsible for the structural and mechanical implementation of the project since my strengths lie far more in this area than in writing computer code. Additionally, unlike Hanna, I have the necessary resources at home to craft. | I was responsible for the structural and mechanical implementation of the project since my strengths lie far more in this area than in writing computer code. Additionally, unlike Hanna, I have the necessary resources at home to craft. | ||
We needed a mount that would allow the servo motors to hover above the guitar strings so they could pluck them individually. The servo motors had to be positioned at a certain distance from each other to avoid interfering with one another when striking the strings. We had already identified this issue through a cardboard prototype. Since guitar picks were to be attached to the motors, increasing the radius of the strike, it made sense to always leave two strings between those being played. | We needed a mount that would allow the servo motors to hover above the guitar strings so they could pluck them individually. The servo motors had to be positioned at a certain distance from each other to avoid interfering with one another when striking the strings. We had already identified this issue through a cardboard prototype. Since guitar picks were to be attached to the motors, increasing the radius of the strike, it made sense to always leave two strings between those being played.[[File:Soldering.jpg|thumb|315x315px|left]] | ||
I decided to attach two motors to one bar. The construction sketch can be seen here: | I decided to attach two motors to one bar. The construction sketch can be seen here: | ||
Since I couldn’t guarantee millimeter-precise construction, and factors like the surface, variations in the way the picks were attached, or different motor models could create height differences, it was necessary to allow for fine adjustments to the height of the mount. For this, I used special adjustment screws that allow the height of the mounting beams to be individually adjusted on both sides. Unlike regular screws, these have two types of threads: the upper thread remains fixed in the wood, while the lower thread can be screwed in and out like a standard screw. This enables precise millimeter-level height adjustments to fit the conditions. | |||
Additionally, the sensors had to be connected to the breadboard. To do this, I soldered cables—each consisting of three wires—of sufficient length to each of the six sensors. I then soldered a connector to each wire to facilitate easy attachment to the breadboard. | Additionally, the sensors had to be connected to the breadboard. To do this, I soldered cables—each consisting of three wires—of sufficient length to each of the six sensors. I then soldered a connector to each wire to facilitate easy attachment to the breadboard. | ||
edits