The second week consisted of implementing a vision system, sonar sensor detection and interprocess communication in order to achieve the interaction of servos' movement with facial tracking via Robot Realm, Python and the mbed. The team was split in 3 different groups :
- Sean : Vision
- Peter : Serial Communication
- David & Hervé : Servos and Interprocess Communication
David and I were responsible for the Interprocess communication during the previous sprint. As IPC was also required in this sprint, we decided to first examine the issue. Investigations revealed that a library issue was causing the IPC implementation to not work.
Secondly, we received a template file from Peter who was responsible for the serial communication between Robot-Realm and the mbed. The template included the RS-232 initialisation/communication and a case statement (table 1). The group's objective involved the implementation of IPC (thread-mutex) and servo motion within the template. The implementation of the system consisted as follows :
- Robot Realm data acquisition (Group 1)
- Robot Realm calculations in Python (Group 1)
- Robot Realm data transmission (Group 1 & 2)
- Reception of data and associated servo movement (Group 2 & 3).
The data emerging from the RS-232 consisted of integers ranging from 0 to 8. Each integer was associated with a specific servo motion as demonstrated in the table below. A case statement was employed to achieve this. Threads, mutexes, serial communication, local display (lcd) and servo motion were all successfully implemented to the project.
The second sprint was very interesting as I believe it brought out positive characteristics to the team. According me, an improvement regarding the communication within the group was significant. I personally feel that we were getting to know each other better as a group, which resulted to us being more comfortable about discussing the project, issues, delegation and responsibilities within the group.
Contrasting Sprint #1 and Sprint #2, chemistry was the element lacking which is now present. The group did not have a sense of direction where each member was doing what he thought was best for the team. Throughout Sprint #2, all members were concerted regarding the project's orientation. Hence, we all were on the same page, knowing the overall & personal expectations. I would personally declare that throughout this sprint , Peter as emerged as the unofficial leader of the group monitoring operations and tasks distributions.
At the other end, I strongly believe that the group poorly performed regarding blog entries, videos and records of achievements. Various elements were achieved but not recorded. As a result, the client was not satisfied at all during the demonstration. For future references, I think the group should discuss how often and under what circumstances blog entries should be recorded.
The lack of available equipment was also a dominant issue during this sprint. For example, each group was allocated 20 minutes before the demonstration in order to set and verify the operation of setups. Due to a lack of USB cable and power supply, we could not benefit from these minutes. Instead, we went into the demonstration without any checks performed, hoping everything would work (unfortunately, it did not work). A proof of concept (video) would have been a major contributor in this case.
Regarding the final sprint, I would advise the division of the class to facilitate the design of 3 to 4 lamps. These lamps would differ by their personality which should be considered by the team in charge (For example: team Nervous, team Shy, team Happy, team Interact...)