This submarine participated in two more friendly matches on this day. The first one was against 6 other submarines. Although there was a lot of cross-fire and many echoes and pings were exchanged, this submarine was able to survive through the whole match and remain afloat.
In the second friendly match, this submarine competed against Piccaddilly Circus and Insert Clever Team Name Here in a 1v1v1 match. This submarine was able to successfully sink the Insert Clever Team Name Here submarine, but was unfortunately sunk by the Piccaddilly Circus submarine.
0 Comments
After 4 more days of rigorous testing, the crew members were convinced that they had come up with a solid system that could communicate with crew members of the same submarine and members of other submarines. On this day, a final showdown occurred under the observation of two members of the Teaching Team. During the competition against BSF <Win> submarine, this submarine was successfully able to launch a torpedo and sink the enemy.
After the installment of a new server, Mumble, the internet issues faced by the crew decreased by a great extent. Every crew member gained access to wired internet through Ethernet cables and transmission of messages over the Internet became much more reliable. The installation of the new server also allowed crew members to test sending messages to crews of other submarines and find problems in software or communication.
Day 16 was dedicated to simulation-based testing of the stations. By the end of the day, the crew members were convinced that the logic behind the stations and Game Play was working as planned. On Day 17, more beep testing was performed and data was collected for the results of beep testing at different times during the day. Unfortunately, no reliable communication of messages could be achieved on this day. Either there were issues with the internet, or with the audio equipment. On the bright side, this testing alerted the crew members to other bugs in their code that were not detected during simulation-based testing and progress was made towards cleaning up these bugs.
Day 14 was devoted to figuring out if the switch from wireless internet to wired internet was making a difference. Two crew members, Riyaz and Kaden, performed beep testing at various times during the day and recorded their results to understand if internet usage at different times during the day was affecting the quality of beeps that they were transmitting. An important point to note here is that, all three crew members were able to transmit and receive their own and each other's messages perfectly when the messages were recorded and played back. However, whenever the messages had to be transmitted over the internet, there were always some issues. On Day 15, the tired members of the crew decided to move away from beep testing and perform simulation-based testing of their software. Now with the merged code for transmission, receive, all three stations and the Game Play state machine, all the software was almost ready for game time. Using the CodeBlocks IDE, crew member Riyaz sent key press events to each of the stations and the Game Play state machine and determined if these were responding appropriately. If issues were found, the other crew members, Kaden and Aditi were alerted and they quickly made changes to clean up the implementation.
On Day 12, the various software branches were merged together so that now there was a version of the software that included every station, had software for a working receiving and transmitting state machine and included all the structures defined for communicating within the dictates of the Communication Protocol. Starting from 21:00 hours on Day 12 until the end of Day 13, all three members of Ed October performed beep testing with each other using a servo to Push to Talk whenever their station wanted to communicate. After so much testing, no reliable results were obtained, as sometimes some crew members were able to receive correct messages and respond appropriately while others were not, and sometimes the situation was the complete opposite. A small demo was performed for a member of the Teaching Team Submarine at 17:00 hours on Day 13. During this demo, two members of the Ed October crew transmitted and received messages from each other over Zoom, a variant of the Discord application. Around 22:00 hours, the crew members sought consultation from other members of the Teaching Team Submarine, and they finally realized that the internet and Discord seemed to be the issue. Now, an executive decision was made to switch to wired internet with the help of the trusty old Ethernet cable.
Over the last three days, the members of the crew further developed their software architecture. Riyaz's modulation libraries were integrated with Kaden and Aditi's transmission and receive state machines and complete testing with hardware was performed to ensure that Kaden and Aditi were able to transmit to each other and receive messages from each other appropriately. Riyaz continued working on his own to create a Game Play state machine that handled all syncing events with other submarines in the ocean and relied upon his software architecture to determine what turn of the game we are on and determine our global position. Kaden and Aditi, on the other hand, worked on implementing the 3 submarine stations in software. Kaden programmed SONAR, Aditi programmed TORPEDO and they both programmed CONN together while sharing screens remotely. The different aspects of software for this submarine are now fleshed out and it is time for a bigger integration before the next checkpoint.
At this point, the members of dEd October decided to branch off and focus on different aspects of the implementation of software on the submarine. One crew member, Kaden, focused on perfecting the implementation of transmission in software, while another crew member, Aditi, focused on implementing receiving. The third crew member, Riyaz, laid out the overall structure for the flow of information between different modules of the code. He created libraries for decoding and encoding messages between tones to dibits. He also created a queuing system that accepted message packets that the station operators could use to communicate their actions and the receiving service would use to receive messages and transfer them internally within the submarine's stations. All of this software was implemented keeping the Communication Protocol for ME 218C 2020 in mind, and so each message was exactly 12 dibits long and contained very specific information as dictated by the protocol.
On this day, one member of the submarine demonstrated a small part of the working submarine to one of the members of the Teaching Submarine. They showed their detailed software architecture in the form of state charts and the electronic design as a circuit schematic. They also showed a servo working correctly to hit a key on the keyboard of each of the stations to initiate Push-to-Talk and LEDs lighting up correctly along with buttons that work.
After finalizing an overall mission plan, the crew of Ed October had to figure out how to implement all the details and meet all the goals for the very first checkpoint.
By this day, they had listed out all the electronic components they would be using, decided how they would be connecting to their microcontroller and drawn out a detailed schematic. They had also come up with 5 state machines that would govern the software architecture of the submarine. They created state machines for each of the stations of the submarine - CONN, SONAR and TORPEDO - and two state machines for transmission and receipt of messages respectively. They had a servo running to begin the process of transmission and a button that would initiate actions. They also included 5 LEDs to give visual cues to the operator about the status of the stations. They were also able to print to the Tera Term application on the machines of operators of every station to show what actions were being taken. While working on these goals for the checkpoint, the crew also worked on polishing previous versions of their software for transmit and receive and testing transmission and receipt of messages of varying frequencies and baud rates. |
|