Project

# Title Team Members TA Documents Sponsor
79 Continuously Recording Microphone
 Brian Song
James Chen
 Dongwei Shi design_document3.pdf
final_paper2.pdf
presentation2.pptx
proposal1.pdf
Team Members: Brian Song (bzsong2) James Chen (jchen251)

Title: Continuously Recording Microphone

Original Post Link: https://courses.engr.illinois.edu/ece445/pace/view-topic.asp?id=30655

Problem: Throughout the course of a day, there are many moments that we wish we could've recorded, such as something funny happening or just something somebody said. However, since that moment has passed and there's no way we could've known to record it, the moment is lost forever.

Solution: We are proposing to create a device that would record audio constantly throughout the day in order to capture these moments. In order to accomplish this with a limited amount of memory used, a certain amount of memory would be allocated for the device to record to, around 15 seconds of audio. When the device is powered on, audio will start recording and begin to use up the memory. Once all of the memory is used, new incoming audio would begin to overwrite the old audio recorded in the beginning. When the user wants to capture a clip of audio, they would press a button and the last 15 seconds of audio will be saved.
The device would be handheld with three different modes of operation. The first mode would be to record audio coming from an external microphone. This would be useful simply when walking around outside while wearing headphones. The second mode would be to record audio coming from an external device such as a phone or computer. This would require the use of two headphone jacks. One would connect to the external device and one would connect to a pair of headphones or speakers. The audio from the external device will be recorded while being routed to the speakers in order for the user to listen to what is being said on the external device. This would be useful for recording clips of conversation over the phone or voice chat. The final mode of operation would be to record audio from an internal microphone on the device and then implement a noise cancelling algorithm in order to record audio in a noisy environment. We would likely use an adaptive filter to implement the noise cancellation, which may prove to yield the best results since audio is constantly being recorded. However, the amount of power and time required to do these calculations may prove to be too high, in which case we may move to using a simpler filter. Both options will be explored extensively and we will choose the best based on results and performance.
When the user decides to save a clip, it will be stored in a different part of the memory such that multiple clips can be saved and indexed in order for the user to easily flip through and listen to each clip. A separate function will be added such that the user can select a clip and shave off audio from the beginning or the end in order to have a more precise clip of what was intended to be recorded.

Subsystems: We would have a total of four subsystems: a control subsystem, a power subsystem, a user interface subsystem, and an audio processing/noise cancellation subsystem. The control subsystem would control where all of the audio data goes and would consist of a microcontroller either coming from an arduino or simply add it onto the PCB. The power subsystem will be powered by a set of replaceable batteries and be able to detect when the batteries are low and need replacing. The user interface would consist of a seven segment display, a couple knobs, and a few buttons. The seven segment display would display the index of an audio clip as well as which mode of operation the device is in. The knobs would be used to shave off audio from a clip where one knob controls where the clip begins and another controls where the clip ends. The buttons would be used to turn on the device, cycle through modes of operation, tell the device when to stop recording, and cycle through previously recorded clips. Finally, the audio processing subsystem would consist of a couple microphones and a PCB. The PCB will filter the audio coming from both microphones in order to produce audio with a significantly reduced amount of noise.

Success Criteria: We would know that our project has succeeded if our device is able to function for at least 16 hours at a time while being able to perform all of the three modes listed above. We would need to be able to record at least 100 clips of 15 second audio and be able to cycle through and crop each of these clips seamlessly. Finally, the noise cancellation operation would be able to produce a difference in audio that is significant, while being time and power efficient.

Cloud-controlled quadcopter

Anuraag Vankayala, Amrutha Vasili

Cloud-controlled quadcopter

Featured Project

Idea:

To build a GPS-assisted, cloud-controlled quadcopter, for consumer-friendly aerial photography.

Design/Build:

We will be building a quad from the frame up. The four motors will each have electronic speed controllers,to balance and handle control inputs received from an 8-bit microcontroller(AP),required for its flight. The firmware will be tweaked slightly to allow flight modes that our project specifically requires. A companion computer such as the Erle Brain will be connected to the AP and to the cloud(EC2). We will build a codebase for the flight controller to navigate the quad. This would involve sending messages as per the MAVLink spec for sUAS between the companion computer and the AP to poll sensor data , voltage information , etc. The companion computer will also talk to the cloud via a UDP port to receive requests and process them via our code. Users make requests for media capture via a phone app that talks to the cloud via an internet connection.

Why is it worth doing:

There is currently no consumer-friendly solution that provides or lets anyone capture aerial photographs of them/their family/a nearby event via a simple tap on a phone. In fact, present day off-the-shelf alternatives offer relatively expensive solutions that require owning and carrying bulky equipment such as the quads/remotes. Our idea allows for safe and responsible use of drones as our proposed solution is autonomous, has several safety features, is context aware(terrain information , no fly zones , NOTAMs , etc.) and integrates with the federal airspace seamlessly.

End Product:

Quads that are ready for the connected world and are capable to fly autonomously, from the user standpoint, and can perform maneuvers safely with a very simplistic UI for the common user. Specifically, quads which are deployed on user's demand, without the hassle of ownership.

Similar products and comparison:

Current solutions include RTF (ready to fly) quads such as the DJI Phantom and the Kickstarter project, Lily,that are heavily user-dependent or user-centric.The Phantom requires you to carry a bulky remote with multiple antennas. Moreover,the flight radius could be reduced by interference from nearby conditions.Lily requires the user to carry a tracking device on them. You can not have Lily shoot a subject that is not you. Lily can have a maximum altitude of 15 m above you and that is below the tree line,prone to crashes.

Our solution differs in several ways.Our solution intends to be location and/or event-centric. We propose that the users need not own quads and user can capture a moment with a phone.As long as any of the users are in the service area and the weather conditions are permissible, safety and knowledge of controlling the quad are all abstracted. The only question left to the user is what should be in the picture at a given time.

Project Videos