Complete 50% of my assignment. Due to family issues, I haven't had the time to start the assignment and it has had an impact on my focus, so I had to resort to this. I would greatly appreciate the help. Thanks
Consists of part of a report and a C Program (What will be required will be in the material below)
Deadline is the 16th March but I would like it to be done earlier if possible
Referencing Style: Harvard
Expected size of the submission: Your report should be about 5 to 7 A4 pages in length (assuming 10pt, normal margins, and excluding appendices). There is no fixed penalty for exceeding this limit but unnecessary verbosity, irrelevance and ‘padding’ make it difficult for the marker to identify relevant material and may lead to some loss of marks.
For anymore information or issues with the files provided, please contact me.
Sorry to ask this as well, but is it possible to label any code written, so I can understand what the code is doing.
What is required (I will add this brief to the materials)
Ubuntu 16.04 LTS and using the terminal within Ubuntu
1 Network and Operating Systems Programming (50%)
1.1 Overview
In the classic Lunar lander games the player controls the descent of a Lunar Lander spacecraft onto the surface of the moon.
You are to write a program to control a lunar lander. You will be provided with a server that models the flight dynamics and propulsion of the lander. Your program should communicate with the server via UDP, using the application layer protocol described in section 2.3.1. The purpose of communication with the server is to control the flight of the lander. Your program should also communicate with a dashboard display to show the current status of the lander. Finally, the program should write to a data logging file to record the inputs from the user and the response of the lander. Figure 1 shows an overview of the system.
Figure 1: Architecture of the lunar lander software
1.2 Controller
2.2.1 Inputs
Using the keyboard of your PC, accept inputs to control the throttle and the strength of the rotational thrust of the lander. You may choose the mapping of input keys to control signals for yourself. This should be documented in your report.
2.2.2 Communications
The controller needs to manage its communications with the Lander server and the dashboard. Communications with the Lander server are by UDP Datagrams, the format of the messages and responses are given in section 2.3.1. Communications with the dashboard should also use UDP. You should design and implement your own protocol for this purpose. This should be documented in your report.
2.2.3 Control Logic
The controller needs to take the requested actions from the user, and the current state of the lander. From these it should generate the control signals to send to the lander server and the outputs presented to the dashboard. It should also log data to a text file. You should organise your program using at least 4 POSIX threads: user input, server communications, dashboard communications, and data loggging. Any data shared by these threads should be protected, as required, by the use of semaphores.
1.3 Lander Server
The lander server is a Java program that models the dynamics of the lander and the lunar surface. You should download the folder Lunar Lander and follow the instructions to build the program. The lander server is packaged as a jar file and executed using java -jar LunarLander.jar
2.3.1 Communications Protocol The server listens for UDP Packets.
Messages to the server, and replies from the server, are formatted as Key:Value pairs, as is done in email headers (RFC822 ) or HTTP Headers (RFC7230 ).
Query messages have the message name as the first key, with a single question mark (ascii 63) as the value.
Command messages that set values or cause actions, have the message name as the first key and a corresponding exclamation mark (ascii 33) as the value.
Reply messages, returned in response to the above, have the message name as the key and an equals sign (ascii 61) as the value.
Request State This message requests the current state of the Lander:
Message send
x x position y y position
O θ orientation (capital O) x’ x˙ horizontal velocity (x single-quote(ascii 39)) y’ y˙ vertical velocity (y single-quote(ascii 39))
O’ θ˙ rate of rotation (capital O single-quote(ascii 39)))
Request condition This message requests the general condition of the Lander.
The keys and values are:
fuel percentage of fuel remaining altitude the radar altitude above the ground contact A keyword describing the general state of the Lander flying moving above the terrain down in contact with the ground in a successful landing crashed in contact or underground in a failed landing
Command Engines This message sets the requested levels on the engines
Message send
The keys and values are:
main-engine percentage throttle setting 0...100 rcs-roll the strength of the rotational thrust -1...1,
+ve is anti-clockwise
Either key-value pair may be used as a single item in the message, or both used in the same message.
Reply from server Request Terrain This message requests the terrain below the lander from its mapping radar
points The number of data points data-x an array of x ground coordinates data-y an array of y ground coordinates
The ground coordinates are supplied one (x,y) pair per line of text. The coordinates are absolute and measured in the same system as the lander state.
If the Lander’s (x,y) position matches a ground (x,y) position, it has reached that point on the ground.
The altitude reported should be the difference between y coordinates of the lander and the ground directly below it.
1.4 Game Dashboard
You are provided with a limited interface on the server, mainly for monitoring the server and debugging. The dashboard provides a more detailed user interface than can be provided by the server.
2.4.1 Requirements
The Dashboard should run on a PC or other computer connected to the controller via a network. You should download the folder at LanderDash and follow the instructions to build the program.
The dashboard can be executed using the command:
java -jar LanderDash.jar
The dashboard accepts UDP datagrams as input. You can modify the communications class of the dashboard to implement your own protocol. You will need to use a protocol that describes the format of the data as sent in the UDP datagrams. As the dashboard is written in Java and your controller is written in C, there is a danger of miscommunicating. A protocol allows you to describe the format of the data, independently from the programming languages, and you’ll have a better chance of success. You should send messages to the dashboard to maintain the current status of all dashboard controls and your protocol should be able to support this requirement.
1.5 Additional requirements
You must include your code for controller.c as appendix 1 in your report. It must be possible also to download the raw code file (controller.c) from the Assessment and to build and run the controller with the lander server and dashboard, exactly as described earlier. Failure to satisfy one or more of these requirements will lead automatically to the award of a mark of 0 for the program as described in section 2.6
1.6 Marking of the program
Your program will be assessed on:
1. the extent to which it satisfies the specified functional requirements
(a) interaction with the user via the keyboard (2 marks)
(b) communication with, and control of, the lander (4 marks)
(c) updating of the dashboard (4 marks)
(d) data logging (2 marks)
2. the quality of the code: correct use of threads, semaphores, and network APIs; functional decomposition, data structures, layout, naming etc. Note, when built with gcc -Wall, your program should compile without errors or warnings. (12 marks)
1.7 What to include about the program in the report
The first section of your report should be entitled ‘The lunar lander controller’ and should include the following:
1. The lunar lander controller
(a) A discussion of the software architecture of your program, focusing in particular on the use of threads and semaphores. What are the advantages and disadvantages of this architecture in fulfilling the functional requirements of the program? How have you managed user input?
(6 marks)
(b) A description and critical evaluation of the protocol that you have used to communicate with the dashboard. To what extent does your protocol help to ensure that communication is reliable?
(5 marks)
(c) A description of the data logging that you have performed. What data have you logged and why? What type of file did you use to store the data? Why did you choose this type? How often do you log data? Justify this decision. At what rate does the size of the file grow while the lander is being controlled?