In week one we were divided up into our teams, my team included Joe, Ian and myself. From the start we were given the basic list of tasks that were expected to be completed. This list of tasks listed that at the end of the sprint the goal was to have a pan and tilt servo operating with overlaying sound. The servo was to follow the movement of a face which was to be detected by a camera using opencv. The whole lot was to be brought together using threads. In our sprint Ian was assigned to the task of face detection through opencv, Joe had the work with the servo’s and I was working with sound. Once the whole lot was complete Ian tried to get the threads in operation but the three tasks would not work together.
From a technical point of view, I felt that our team performed to a certain extent, however I felt that the problems arose when the team began to work together. I felt that the problem was the linking together of all of the pieces. Sprint one was the foundations for the project and while our demo showed that the project didn’t operate all together we did manage to operate the components separately. My task was to get the sound operating. At first this was quite difficult as the pi will default the sound output to the HDMI input and the settings must be changed through the terminal. At first this fix did not take effect and after a few reboots I decided to re-perform the commands through the terminal, but I also changed the settings through the pi-configuration user interface which, when both commands were performed at the same time, forces the audio to play through the 3.5mm headphone jack.
With the output problem solved it was then time to resort to the method of playing the audio track on the pi with an audio player that could be called using a python script. Here there was a great choice of methods to import and play the audio file, which I did try experiment with. It was possible to use pygame and other applications, importing the player and using it to play the track through the script. However, I found that the os library had a straight forward function which allowed the sound to be played. The only struggle here was to try get the clip to stop when the servo had stopped moving. However, I am unsure as to whether a function stopping the sound would have worked considering the large amount of jitter in the servo. If this is a current supply issue then the stopping function would’ve worked correctly, if it was caused by a noisy gpio signal then the movement would have to be monitored and the sound would have to be limited to a movement greater than a certain movement angle.
In terms of teamwork, I personally feel like our team did not quite gel in the first week of the sprint. I feel that this may have caused a problem as the communication level was not up to the standard of the other teams. The communication had picked up coming closer to the end of the sprint, however, this was maybe a little too late as we had all tried working alone for too long and when it came to putting things together we didn’t have enough time.
Looking back over the sprint I have learned one major thing, Communication is the key to teamwork. I think for the next sprint we should consider a way to remove the jitter from the servo controls as once a lamp is brought into the mix, the jitter will begin to be a greater problem than it already is. I also think it would be ideal if maybe a lamp model was picked and purchased as I feel that teams may be ready to move onto the lamp during the next sprint, Purchasing the lamps would have no effect if they were not ready but I believe that once my team has caught up that we will be ready to move on to perfecting the current lamp-less model and then, once perfected, move on to the lamp.
William Post 3