Progress of project for week #

• Week 1 – 2 :
  Briefing, Attended Introduction course (on 3D Printing, Arduino, and COMSOL)
  Initially, we wanted to make a drone but did not have a use case for it. A suggestion was given that  we can think about how to make a land mine detection drone.
  Brainstorm and research about how to proceed. Learnt that there are a wide variety of land mines, and many land mines are increasingly being constructed with different material and less metal.
  Read up on different methods on how to detect land mines.
• Week 3:
  We decided that the previous idea was unfeasible and decided to scrap the idea. Unfortunately, we did not have any ideas to proceed on. We approached Dr Ho for suggestion and advise. He suggested a few ideas for us to consider. One of the scenario that he gave us was with regards to Loud super cars disturbing the heartlands with their loud engine during late night or wee hours in the morning. The plan was to create a device to catch these acts on video so as to deter such drivers from disrupting the neighborhood.
  Therefore, we decided that our project would to make a “Loudness Camera”. A device that records a short video clip of the loud cars and the audio after the noise level exceed a certain threshold volume.
  We researched on the parts that we would need and went to purchase the parts. Some parts required a period of time for it to deliver. We decided to work with arduino first as we attended the introductory course.
  Submitted Risk Assessment.
• Week 4:
  The RTC DS1337, arduino uno, ADS 1115 16bit ADC and the sound sensor arrived. We tested the parts individually, following various tutorials online.
• Week 5: Progress Update 1
  Arduino Camera module OV7670 arrived. We followed tutorials online to test out the camera module to take picture and test the quality. The camera module used most of the input/output pins of the arduino uno. We were unable to attached both the sound sensor and the camera module to the arduino uno simultaneously due to the lack of input/output pins. We realised the arduino camera take awhile to take and process a photo.
• Week 6:
  I borrowed a microsd card and adapter from my friend. I bought a micro sd card arduino module to test reading and writing data onto the micro sd card. The idea was to be able to save the raw data of image taken or the sound sensor data onto the microsd card. There were two different tutorials that we tested for the OV7670 module, one saving the image taken directly onto the computer, another saving the raw data image onto the sd card first.
• Week 7: Progress Update 2
  The idea was to have two device, one controlled by an arduino uno and another (a certain distance apart) controlled by a raspberry pi (rpi). The arduino uno device would detect the sound level, if it exceed the threshold volume, it would communicate wirelessly to the rpi to prepare the camera to take a video. The rpi have an additional sound sensor to detect the sound level again.
  We planned to purchase a ESP8266 wifi module, and rpi camera module as the arduino camera was not very suitable in taking the video. We decided to use the rpi to record the video.
  
• Week 8:
  Douglas experimented with the arduino sleep mode. Realised the RTC we previously bought did not have an alarm that can wake the arduino when it is sleeping and only can keep track on time externally. So I purchased a different type of RTC module.
  Kohong tested the rpi camera module.
  Tested the ESP8266 wifi module, tried using with the arduino uno, ftdi ft232rl. Was not able to run the AT firmware on it, tried to flash the firmware using online tutorial but was not successful, could get it to appear as an access point on my phone detected wireless network. Was going to purchase another ESP8266 wifi module but decided that the rpi would be able to detect sound just as fast then it would be for the arduino to send commands to the rpi through wireless.
• Week 9: Progress Update 3
  Attended an entrepreneurship workshop. Decided to do away with arduino component of the schematic and just have the rpi with the sound sensor, camera and additionally a mini usb microphone to record the sound.
• Week 10 – 11:
  Douglas and Jie hauw worked on designing the casing for the device. While Ko hong and Le jia worked on the codes and testing of the rpi.
  We learnt that it is important to ensure that there are sufficient filament when sending our print job. Otherwise, the print job will fail as the printer would just print out air.
  It is important to give tolerance when setting the dimension. For example, we had to revised our versions as the lid a few times. The  lid that we printed for our case was initially too tight (tight fit but very hard to remove), too loose (as we gave too much room (0.5mm on each side is too much, at least in our case), lastly a perfect fit (0.1mm on each side, able to fit snugly and remove with ease).
• Week 11: Progress Update 4
  Tested the rpi with camera at night with Kohong in Potong Pasir. We access the rpi using SSH by connecting the laptop to the rpi access point and send script to it using PuTTy. We tested two different camera at different positions and directions of the camera. (Oncoming traffic vs Traffic moving away from the camera), ( Under a lamppost, In a different spot where there are less lights, etc.). Unfortunately, we were not able to see any of the license plate from the videos.
  The videos had different issues.
• Week 12:
  Le jia bought a mini usb microphone and wrote a code to record sound. The script would record 1) a sound file using the microphone, 2) a 10+ seconds video clip using the rpi camera module when the sound detector module detect the threshold level.
  The rpi would record and save the 2 as separate files and we have to combine the two raw data files using a converter.
  Edited the resolution of the camera in the code and tested it with a blue plastic filter to see if it would reduce the glare from the lights of the vehicle. Was still unable to see the license plate. It helped reduce the intensity of some of the various light source, but still unable to see the license plate.
  Thought that a iphone screen protector could help reduce glare so bought one to try but was sadly mistaken. The video just became blurry, bad idea.
  Went to find a usb led lamp to try to light up the background of the rpi camera, perhaps it can help to get a clearer record of the license plate.
  Read an article on how “Cameras are governed by a dismal weakest-link principle: whichever camera system component (lens, sensor chip, lighting, file format) is least resolving, limits the total system performance to that component’s weak performance The weakest link is the lens, and the lens choice becomes the critical factor in achieving performance. (http://www.truetex.com/raspberrypi)”
  Plan to try out different kind of lens with the rpi camera modules and see if it help with the resolution. The lens we plan to try with it is the OV7670 mounted lens we had bought previously ( but we will need to make a mount for it, and remove the current lens) as well as other lens that kohong have in his possessions.
  We would use winSCP to access the files stored on the rpi. Handbrake video converter to convert the raw video file to a playable file formatHave not tried changing the lens of the camera. Tried testing the camera at a different place in the neighborhood at night. One where the vehicle would slow down for a hump. I thought that the hump and the better lighting would help out with the video quality. I tried using the usb lamp as well but I think it did not contribute much. Out of the video test, we manage to capture a lorry license plate. I feel that the normal camera will be suited for this as compared to the low light camera as it was clearer and it would probably be better as the device would likely be functioning from the night to the early morning.
  Some issues faced was despite tuning the sound sensor with the screw driver, I was unable to get it to trigger as the vehicle passes by. So in order to test the camera i manually trigger it by a python script through the rpi access point. Another issues was that since the rpi was not connected to the internet, it did not have an updated timestamp as it save the video/audio recording.
  The sound sensor could be adjust by a potential meter on it, but when i was adjusting it, it was either permanently on or it was not sensitive enough to detect the vehicle sound. I am not sure why we thought it work properly previously.
  
  The timestamp issues would be addressed by fitting an RTC module to it, will worked on that today. (https://cdn-learn.adafruit.com/downloads/pdf/adding-a-real-time-clock-to-raspberry-pi.pdf) This tutorial is great to follow, got the rtc attached and seems to be working!

  Was thinking of using the sparkfun sound sensor with the rpi, (either gate output [can use the gpio pin (but would be similar to the other sound sensor] or envelope reading which is terms of 0 to 1023 ) rpi does not have an adc converter but we had earlier bought ads1115 adc converter! Both the RTC and the ads1115 requires the use of SDA and SCL gpio pins.
  Since I2C is a bus, online tutorial say many I2C devices can be use on an I2C bus and up to 8 devices can be connected. We will just connect all the SDAs together and all the SCLs together.
  Met with le jia to try to adjust the sound sensor, but we found that video feed became blurry out of the blue. We tried to adjust the software code by trying out the different camera resolution and removing the camera preview to see if it will make the video feed clearer. Unfortunately that did not work. After reading alot of website saying how the focus of the lens might be making the video blur. We decided to use a tweezers to try to adjust the lens of the normal light camera. As we felt that the normal light camera was more suited to be used than the low light camera. Since the device would be operational from late night to early morning and the low light camera would sometimes give a different color. When we adjusted the lens, it became clearer a little. However, we might have adjusted too much and broke some connection. The rpi could not sense any data from the sensor. We tried adjusting the sunny connector and the ribbon as we thought that maybe it was just some loose connection. But after many attempts, it seemed that maybe we spoilt the normal light camera. We tried using the low light camera and it could work but it was blur too.

  For the RTC, I realised that when we tried to connect it to the GPIO while the rpi is on. It would somehow reset the rtc but if we shutdown the rpi first and connect them, it would work fine and can show the updated time.