ANU 留学生作业 写作、Networks程序 写作、Java,Python,c/c++

” ANU 留学生作业 写作、Networks程序 写作、Java,Python,c/c++1 | ANU College of Engineering and Computer Science September 2020Gliding in SpaceAssignment for all students of Systems, Networks and Concurrency 2020This is a carefully evaluated and marked assignment. Thus extra care is expected on all levels.OverviewCoordinating behaviours and resources in a concurrent and distributed way is at the heart ofthis course. The background this year is a swarm of physical vehicles in 3-d space.The code framework which will model and simulate a swarm of vehicles showing default behaviourswhich keep them In motion, together as well as collision-free is provided to you. All vehicleshave a local charge to keep them alive. For physical reasons yet unknown, the vehiclesreplenish their charge to full by passing energy globes in close proximity. Vehicles which runout of charge mysteriously disappear. Vehicles constantly consume a little bit of energy to keeptheir on-board systems running, and consume more substantial amounts of energy when acceleratingor decelerating.Sensors, Actuators CommunicationEach vehicles is operated by a dedicatedtask which has access to local sensors, communicationinterfaces and actuators.The sensors include position, velocity andacceleration as well As current charge. If thevehicle is close enough to one or multiple energyglobes to utilize them, the sensors alsodisplay the position and current velocity of all close energy globes.The actuator system consists of setting an absolute destination position and throttle value. Theunderlying cruise control systems automatically handles the steering and acceleration. Oncethe destination point has been reached the throttle automatically switches back to idle whichmeans that default swarming behaviour takes over. The vehicles do not slow down when approachingthe destination point and rather pass through the destination point. This helps todata留学生作业 写作、Networks作业 写作、Javakeep the controls fluent and the vehicles in motion. Collision avoidance reflexes are always activeand prevent vehicles from crashing into each other. Note that destinations might becomeunreachable, if multiple vehicles are bound for the same destination.The vehicles are also equipped with a message passing system which allows to broadcast amessage which will be received by all vehicles in close proximity. This is asynchronous andthere is no feedback whether any message has been received by any vehicle unless anothervehicle actively sends a message in response of course.Finally there is also a function which allows direct access to the underlying, secret clock of theworld. Wait_For_Next_Physics_Update will put the task to sleep until anything actually happened(which includes communication). This relieves the vehicles from busy waiting on theworld to change.All the above controls are found in Sources/Vehicle_Interface/vehicle_interface.ads.2 | ANU College of Engineering and Computer Science September 2020The AnimationThe provided graphical animation of the swarm offers third person views as well as the viewfrom one of the vehicles while it is passing through the swarm. The communication range canbe visualized by drawing connecting lines between all vehicles which are currently in communicationrange. The colours represent their charging state as well as the control state. Turquoisevehicles are currently Following their swarming instincts are not explicitly controlled by the associatedtask. The colour saturation reflects the level of charge. Once vehicles go into manualcontrol (throttle and destination is set) they turn to a more red colour schema. The energyglobe(s) are dark ruby coloured spheres.Design ConstraintsThe final solution which is requested from you should be deployable on actual vehicles. Henceonly the provided interfaces to physical sensors and forms of communications are allowed.Looking underneath the hood is still encouraged of course if you want to see how such asimulation can Be implemented on a computer system. Bypassing the provided interfaces andusing information from inside the simulator is obviously counterproductive for any future physicaldeployment and hence not allowed. Nevertheless the first stage of the assignment will allowyou to introduce additional means of communication which can not necessarily be physicallyimplemented.Timing ConstraintsAll calculations inside the vehicle tasks have an implicit deadline given by the update from theunderlying physics engine. This deadline is not hard as seen by the local tasks, yet many tasksoverrunning this deadline concurrently will slow down the simulator. Simulated time is not affectedby this only the update time intervals will become larger.Design GoalsThe overall design goal is to keep as many vehicles alive as possible for as long as possible. Asenergy globes can Only be discovered locally, communication is required, as well as coordinationbetween the vehicles as all swarm members heading for the some destination at the sametime will not lead to many of them making it there.3 | ANU College of Engineering and Computer Science September 2020The task can be solved in four stages:a. Allowing a central coordinator.b. Fully distributed.c. Multiple energy globes.d. Find harmony.Stage a still allows for a central coordinatorto be introduced and all tasksare allowed to communicate withthis entity (or multiple thereof). Theimplementation of those central instancescan employ shared memorybased as well as message based forms of communication. Some are obviously questionable toimpossible in a Physical deployment of your system, yet this stage might help you to developideas which can then be considered for the second stage.Stage b does not allow for a central coordinator and all planning and scheduling now needsto be done on the individual vehicles only using local communication. This is hard. If you areconfident that you are up for stage b straight out then you do not need to implement stage a.Stage c requires further coordination between vehicles as multiple energy globes are to beconsidered. Assume that you do not know how many globes are in existence, yet utilize theadditional redundancy which is detected at runtime to enhance the overall robustness of yourswarm charging method. To test this you will need to go to the package Swarm_Configurationand change Configuration to Random_Globes_In_Orbits. Globes can appear and vanish atrandom, yet there will Be a minimum of 2 globes around at all times.Stage d requires all of the above plus that the swarm shrinks itself to a specific size. This sizeis a constant (Target_No_of_Elements) which is known to all vehicles, yet they do not know(initially) how many vehicles there are in total, or whether they themselves are scheduled fordestruction. This stage will require a fully distributed method to share information and agree onaction (in this case, to purposefully let certain vehicles run out of energy and vanish).CriteriaThe first criterion is to get over the initial phase without anybody dying. This can be a impossible,if still nobody found an energy globe before the initial charges run out. Dont worry aboutthis case this is just nature and you cannot do anything about it.Yet once one or multiple globes are found you need to make sure that the information is spreadeffectively.Now comes the real challenge of how to coordinate the vehicles. Find ways to coordinate theirpaths. This might be leading to different strategies in stage a and stage b.The Programming FrameworkThe provided code has been successfully compiled and tested on the lab computers and: Linux: Ubuntu version 10, 14.04, and lab computers. Depending on the Linux version, itmight be necessary to install glutg3 and glutg3-dev (via a package manager, if you are lucky). Mac OS: PowerPC and Intel (32 and 64bit), tested on 10.5 to 10.15. Windows: tested on XP, Vista, Win7 and Win10. The freeglut library needs to be in the samedirectory as the executable (already placed to the right spot in the provided project).Please note the different Project files which refer to different operating systems and select theone fitting your computer when opening the project.Parts of the provided framework are based on the Globe_3D project (an OpenGL 3D engine),which is maintained by Gautier de Montmollin.4 | ANU College of Engineering and Computer Science September 2020DeliverablesYou need to submit a report (in pdf) as well as your code (only the source files inside the directoryStudent_Packages – please do not submit the whole framework or your binary files). Thereport is your chance to convince us that your concept is great even though your code mightnot have run according to expectations. Conversely, even though your code might be a strikeof genius, we might not have recognized it without your great report along with it.Report Documentation of your design. Specific emphasis should be given to explain your designdecisions. Give reasons for each of those. Make clear which constraints you employedas driving concepts, which have been considered, and which have been purposefullyignored (for instance to allow for a cleaner, easier maintainable design). Provide documentation of your test runs. Give a precise motivation for each of your tests.The following questions might help you to evaluate and describe your design: How does your design scale? Do you provide for graceful degradation in case that parts of your system becomeunresponsive (a mysterious vehicle disappearance case)? Do you consider your design dependable and maintainable and why (or why not)?If you require help in technical/scientific writing, please do not be too shy to ask for it.CodeSubmit only the manipulated packages (vehicle task message structure) together with thepackages which you added on top. Your code will evaluated according to common professionalpractice. We do not Enforce a specific coding schema, but request consistency and a generalhigh standard on the basic coding level. Make sure all your identifiers have good names, allscopes and access constraints are set as tight as possibly, and full use has been made ofcompile time checks. All your code will be read. We do not have the capacity to provide detailedcomments on all code, but will refine the provided feedback on individual request in thelimits of our time.GeneralUse graphical or any other means to express your ideas as precisely as you can. Overall assignmenttime is four weeks (which includes two weeks of semester break), so we expect a work ofprecision and care. Exact due date and submission procedures will be announced on the websiteand forums.Guidelines for the marking are: (30%) Functionality of your program – does it implement stage a, b, c or d? (30%) Elegance and strictness of your design. (30%) Clarity of the report. (10%) Provided documentation about test runs.Expect to be limited to A credit (CR) range marks if your design only considers stage a solutionsand to find yourself in high-distinction (HD) range if your design is a convincing and competesubmission for stage d. Allow yourself plenty of time to come up with a solid concept first.Without a clear idea you are bound for chaos in this assignment.This is only a guide. We will feel free to give you more marks if your code is outstanding or yourreport is an outstanding example of technical writing.如有需要,请加QQ:99515681 或邮箱:99515681@qq.com

添加老师微信回复‘’官网 辅导‘’获取专业老师帮助,或点击联系老师1对1在线指导