Overall

During mid break, each member of our group read a lot of tutorials about implementation methods and modules (but these did not involve specific physical implementation), so at that stage, we focused on the input of knowledge and the way of implementation. After we clarified our thinking, we decided to start with the recording function.

Prior to this, we also spent a lot of time discussing what kind of cooperation method to adopt:

1. Everyone is responsible for their own parts and finally put the work together;
• Advantages: no teamwork, the project progress is self-controlled;
• Disadvantages: When you encounter difficulties, you can only solve yourself, because other team members have not learned this part of the knowledge, and they have a low possibility to be able to help yourself.
2. Discuss and collaborate on different parts of the same function together.
• Advantages: For the same problem, everyone has different views and solutions, and the conclusions drawn after their respective studies and discussions are often more reasonable;
• Disadvantages: It takes a lot of time to discuss.

Finally, considering that everyone has no engineering background and skills, we chose the second method. Throughout the last week and this week, as we expected, we spent a lot of time discussing more detailed processes, explaining ideas and communicating understanding. Finally, after discussing with other UQ student with IT and EE backgrounds and tutors, we have a basic understanding of our project implementation, including the sensors used, the language of coding, the design of Arduino, and a general imagination of future works.

Progress

Our implementation is divided into two stages, the software stage and the hardware stage.

According to all the functions of our project, we need to first implement the software part with code (Python), and the interaction mode among them is replaced by keyboard. And if you enter the hardware stage, you can use different signal input methods in Arduino to replace the buttons (this is the most reasonable way we currently think of). In addition, we have realized the function of sound recording, and can record sounds of different lengths according to the user's operation.

Function and key introduction:

1. Dropper
• R: The computer automatically records after pressing. Keep
• pressing and holding until recording is released, which means that the recording ends; the generated audio file is stored in the dropper folder; the audio file is named raw sound
• Note: Only one audio file can be stored in the dropper. If there is a new recording file, the original file will be overwritten.
2. Test tube
• M: The audio file in the dropper is transferred to the test tube folder, and the audio file in the dropper is deleted; the audio file is named sound
• T: The audio file in the test tube is transferred to the flask folder, and the audio file in the test tube is deleted
• D: delete the audio file in the test tube
• P: Play audio files in the test tube folder
• Note: Only one audio file can be stored in the test tube. If there is a new recording file, the original file will be overwritten.
3. Flask
• Space: Play all audio files in the flask folder at the same time (simulate the effect of mixed music)
• S: delete all audio files in the flask folder
• Note: Multiple audio files can be stored in the flask; simultaneous playback means overlapping playback of multiple sound tracks
4. Jars
• C: copy the music in the jars folder to the flask
• Note: The music in the jar is preset with 1 audio file; named as music frame

Feedback:

In the discussion stage, we have the following two problems in total, and provide different solutions.

Change in recording method

At the beginning of mid break, we planned to set the recording module on the dropper, but after understanding that the Arduino circuit board only has a few tens of K of storage, the solution we came up with was to add an SD card as a reservation. However, if you use this method, music files still need to be transferred to the computer for music synthesis (music and synthesis must be used in a laptop), and later need to be transferred back to the speaker. This method seems to be superfluous, and we do not know of any suitable transmission method (WIFI or Bluetooth?). At this time, we already have the idea of using the computer directly as a storage. After discussing with the tutors, we are more affirmed with this idea (developing a small program; the user's actions can trigger the program to achieve a certain operation purpose). In order to perfect this idea, for recording and playback, we plan to connect the Bluetooth headset / Bluetooth speaker to the computer in advance, and place the headset in the dropper / Bluetooth speaker under the table (although the sound is not from the test tube or flask , this method is feasible and able to simulate the real use environment. If the speaker is placed in a test tube or flask, the increase in material costs and whether it is necessary to become additional content we need to discuss).

Add jars

In the initial stage of designing project facilities, we did not have jars. Because there is a need to obtain a music frame from user feedback, we designed an interactive way of tapping to switch the default set of music frame. But when designing the buttons, the same interaction method and sensors have been set on the same flask (shaking to mix music and play music; because they all use the tilt switch. According to the design principle of the tilt switch-- it calculates the number of impacts of the two steel balls included to trigger the signal, this means that although the sensor can be used to customize the number of impacts to trigger the switch, there is only one chance. Set the number of impacts to 2 and 3 to trigger different functions cannot be achieved), so we will extract this function and put it in the jar.

At the beginning, we also tried to set up multiple music files in a jar, and tapped to achieve the function of switching songs (similar to the music player function). However, when discussing the technical implementation, we found that if there are multiple songs, it is difficult to determine which one needs to be transferred to the flask. We are still discussing this technical difficulty, so as far as the current project progress and progress are concerned, we temporarily decided to keep only one default music frame in each jar (the user still has the right of choosing whether to use jars and which jar they are planning to use), so that we will not waste a lot of time on this function, but focus on our core functional task flow.

Changes in sensor selection

It is precisely because of our further understanding of functions and triggering conditions that we found that there are two interaction modes that coincide in the implementation phase (tilting and shaking). When we don’t understand the design principle of the tilt switch, we think that it can achieve different effects according to identify different impact times, but the fact is not what we expected, we have to change the sensor for detecting shaking to vibrating mini motor. But after I inquired about the principle of this sensor, I still have doubts in understanding, and I am not sure whether this sensor can help us achieve the final effect, so I need to read more related materials.

In addition, because there are many interactive methods in our project and many sensors are used, we have not been able to find a usable sensor to implement the delete function (originally it was a tilting action on the trash can, but this action has been related the corresponding operation: music is transferred from the test tube to the flask), so we need to design a new interactive method as the delete function. We currently have no good ideas and need further discussion. At present, we have temporarily designed this function to use a button as a trigger. If we have time in the future or come up with a better idea, we will change it (also because this is not a core function, and if you use a button, it will not have a great impact on the final result).

Next week

• Continue to design and programing
• Consider the material of the physical equipment. Our original plan was to use cardboard, but light will be added later, and cardboard is not the best choice; the tutor recommends that we use plastic chemistry experiment equipment specially designed for children, so we will go to the website to evaluate its feasibility