» Assessment » Assignment 1 “Gliding in Space”
In this assignment, you will model and simulate a swarm of vehicles to keep them in motion without collision.
Source code submission deadline: 23:59:59 Thursday 30 September (Week 8) Report submission deadline: 23:59:59 Friday 1 October (Week
8)
Project skeleton for Assignment 1
Overview
Coordinating behaviours and resources in a concurrent and distributed way is at the heart of this course. The setting for this assignment is a
swarm of physical vehicles in 3D space.
We have provided a code framework that models and simulates a swarm of vehicles that follow simple default behaviours to keep them in
motion together and avoid collisions. All vehicles have a local charge to keep them alive. For physical reasons yet unknown, the vehicles
replenish their charge to full by passing energy globes in close proximity. Vehicles that run out of charge mysteriously disappear. Vehicles
constantly consume energy to keep their onboard systems running and consume substantially more energy when accelerating or
decelerating.
Sensors, Actuators & Communication
Each vehicle is operated by a dedicated task that has access to local sensors, communication interfaces and actuators.
The sensors include position, velocity and acceleration, as well as current charge. If the vehicle is close enough to one or more energy globes
to utilize them, the sensors also display the position and current velocity of all close energy globes.
The actuator system consists of setting an absolute destination position and throttle value. The underlying cruise control system automatically
handles the steering and acceleration. Once the destination point has been reached, the throttle automatically switches back to idle, which
means that default swarming behaviour takes over. The vehicles do not slow down when approaching the destination and rather pass through
the destination point. This helps to keep the controls fluent and the vehicles in motion. Collision avoidance reflexes are always active and
prevent vehicles from crashing into each other. Note that a destination might become unreachable if multiple vehicles are bound for the same
destination.
The vehicles are also equipped with a message-passing system, which can broadcast a message that will be received by all vehicles in close
proximity. This is asynchronous, and there is no feedback on whether any message has been received by any vehicle – unless another
vehicle actively sends a message in response.
Finally, there is also a function that allows direct access to the underlying, secret clock of the world. 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 for the
world to change.
All the above controls are found in Sources/Vehicle_Interface/vehicle_interface.ads .
Visualization
The provided graphical animation of the swarm offers third-person views as well as the view from one of the vehicles while it is passing
through the swarm. The communication range can be visualized by drawing connecting lines between all vehicles which are currently in
range. The colours represent their charging state as well as the control state. Turquoise vehicles are currently following their swarming
https://cs.anu.edu.au/courses/comp2310/assessment/assignment1/
https://cs.anu.edu.au/courses/comp2310/assessment/
https://www.timeanddate.com/worldclock/fixedtime.html?msg=COMP2310+Assignment+1+Due&iso=20210930T2359&p1=57
https://www.timeanddate.com/worldclock/fixedtime.html?msg=COMP2310+Assignment+1+Due&iso=20211001T2359&p1=57
https://gitlab.cecs.anu.edu.au/comp2310/comp2310-assignment-1
instincts are not explicitly controlled by the associated task. The colour saturation reflects the level of charge. Once vehicles go into manual
control (throttle and destination are set), they turn to a more red colour schema. The energy globe(s) are dark ruby coloured spheres.
Design Constraints
The solution that you produce should be deployable on actual vehicles. Hence only the provided interfaces to physical sensors and forms of
communications are allowed. “Looking underneath the hood”, for example, using global information about times or positions, is useful to help
understand the problem. Bypassing the provided interfaces and using information from inside the simulator is obviously counterproductive for
any future physical deployment and hence not allowed. Nevertheless, the first stage of the assignment will allow you to introduce additional
means of communication which cannot necessarily be physically implemented.
Timing Constraints
All calculations inside the vehicle tasks have an implicit deadline given by the update from the underlying physics engine. This is not seen as
a hard deadline by the local tasks, yet if many tasks overrun the deadline, it will slow down the simulator. Simulated time is not affected by
this – only the update time intervals will become larger.
Design Goals
The overall design goal is to keep as many vehicles alive as possible for as long as possible. As energy globes can only be discovered
locally, both communication and coordination between vehicles are required, as all swarm members heading for the same destination at the
same time will result in many of them failing to reach it.
The task can be solved in four stages:
1. Allowing a central coordinator.
2. Fully distributed.
3. Multiple energy globes.
4. Find harmony.
Stage 1 still allows for a central coordinator to be introduced, and all tasks are allowed to communicate with this entity (or multiple thereof).
The implementation of those central instances can employ shared memory based as well as message based forms of communication. Some
are obviously questionable to impossible in a physical deployment of your system, yet this stage might help you to develop ideas that can
then be considered for the second stage.
Stage 2 does not allow for a central coordinator, and all planning and scheduling now needs to be done on the individual vehicles only using
local communication. This is hard. If you are confident that you are up for stage 2 straightaway, you do not need to implement stage 1.
Stage 3 requires further coordination between vehicles as multiple energy globes are to be considered. Assume that you do not know how
many globes are in existence, yet utilize the additional redundancy which is detected at runtime to enhance the overall robustness of your
swarm charging method. To test this, you will need to go to the package Swarm_Configuration and change Configuration to
Random_Globes_In_Orbits . Globes can appear and vanish at random, yet there will be a minimum of 2 globes around at all times.
Stage 4 requires all of the above, plus that the swarm shrinks itself to a specific size. The target size is a constant
(Target_No_of_Elements ) that is known to all vehicles, yet they do not know (initially) how many vehicles exist or whether a particular
vehicle is scheduled for destruction. This stage will require a fully distributed method to share information and agree on action (in this case, to
purposefully let certain vehicles run out of energy and vanish).
Survival
The first priority is to get over the initial phase without anybody dying. This could be impossible if no vehicle finds an energy globe before the
initial charges run out. Don’t worry about this case – this is just nature, and you cannot do anything about it.
Once one or more globes are found, you need to ensure that the information is spread effectively.
Now comes the real challenge of how to coordinate the vehicles. Find ways to coordinate their paths. This might lead to different strategies in
stage 1 and stage 2.
extension
While the goal for most students will be maximising the number of surviving ships, you may want to explore alternative behaviours. If so,
talk to your tutor to confirm that these behaviours are consistent with the assignment goals.
Some videos of example possible behaviours:
Charging groups
Coordinated straight approaches
Counter rotating rings
Cross
Fast ring Chase
Fast ring Comm_links
Fast ring
Funnel through the globe
Giant grid
Leading the globe
Pulsating rings
Pushing in ring
Roam around the globe
Slow pushing
Programming Framework
Refer to the README.md file in the assignment repo for instructions on building and running 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.
Deliverables
You should fork the assignment repository to your own namespace in GitLab. You will be marked by your tutor based on the last commit
pushed to GitLab before the assignment deadline. Your assignment repository should include:
a report in PDF format named report.pdf ; and
your source code in the form of added or modified source files inside the directory Student_Packages – please do not modify other
parts of the provided framework, or add binary files to your Git repository.
Report
The report is your chance to convince us that your concept is great – even though your code might not have run according to expectations.
Conversely, even though your code might be a work of genius, we might not have recognized it without your great report to complement it.
Documentation of your design. Explain all major design decisions, and give clear reasons for each. Make clear which constraints you
employed as ‘driving concepts’, which have been considered, and which have been purposefully ignored (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 become unresponsive (a mysterious vehicle disappearance
case)?
Do you consider your design dependable and maintainable, and why (or why not)?
References:
Marc Tischler on Scientific Writing
Uwe Zimmer on Typesetting for Technical Writing
If you require help in technical/scientific writing, please ask the class forum or your tutor.
Code
Your code will be evaluated according to common professional practice. We do not enforce a specific coding schema but expect consistent
and high-quality code. Make sure all your identifiers have good names, all scopes and access constraints are set as tight as possible, and
make full use of compile-time checks. We will read all your code; we cannot provide detailed comments on every part but will refine the
provided feedback on individual requests within the limits of our time.
General
Use graphical or any other means to express your ideas as precisely as you can. Overall assignment time is four weeks (which includes two
weeks of semester break), so we expect a work of precision and care.
Guidelines for the marking are:
(30%) Functionality (does the program implement stage 1, 2, 3 or 4?)
(30%) Elegance and strictness of design
(30%) Clarity of report
(10%) Provided documentation about test runs
Expect to be limited to a credit (CR) mark if your design only considers stage 1 solutions. In contrast, you may receive a high distinction (HD)
mark if your design is a convincing and complete submission for stage 4. Allow yourself plenty of time to come up with a solid concept first.
Without a clear design, you may expect chaos during implementation.
We may award you more marks if your code is outstanding or your report is an outstanding example of technical writing.
UPDATED: 27 Sep 2021 / RESPONSIBLE OFFICER: Director, School of Computing / PAGE CONTACT: Josh Milthorpe
https://globe3d.sourceforge.io/
https://gitlab.cecs.anu.edu.au/comp2310/comp2310-assignment-1
https://cs.anu.edu.au/courses/comp2310/papers/Sci-Writing.pdf
https://cs.anu.edu.au/courses/comp2310/papers/Typesetting.pdf
mailto:director. .au
mailto:josh. .au