RWA 2: Search and Rescue Mission Planner#

Overview#

Due Date	March 23, 2026, 11:59 PM EST
Total Points	50 points (Design: 6 pts, Implementation: 44 pts)
Submission	Canvas (ZIP file: `firstname_lastname_rwa2.zip` containing the project folder)
Collaboration	Individual work only. AI tools are NOT permitted (see policy below).
Late Policy	10% deduction per calendar day, up to 3 days. Zero after 3 days.

Use Case: Disaster Response Operation

Read the following domain description carefully. You will use it to build your class diagram and then implement the system.

Robots

A regional disaster response agency coordinates search and rescue operations after natural disasters. The agency deploys a fleet of heterogeneous robots to search a disaster zone. Each disaster zone is divided into multiple sectors that must be systematically searched.

The agency operates two types of robots:

Aerial drones fly over sectors to perform wide-area surveillance. Each drone has a maximum altitude (in meters) and cannot operate in sectors where the required search altitude exceeds its limit. Drones consume battery at a rate of 5% per search operation. When a drone searches a sector, it performs an aerial sweep and reports the percentage of the sector area it was able to cover.
Ground crawlers traverse terrain on wheels or tracks. Each crawler has a maximum speed (in m/s) and a set of terrain types it can handle (e.g., “rubble”, “mud”, “pavement”). A crawler cannot be assigned to a sector if the sector’s terrain type is not in the crawler’s capability list. Crawlers consume battery at a rate of 8% per search operation. When a crawler searches a sector, it performs a ground sweep and reports the number of survivors located.

Common Robot Characteristics

All robots share the following characteristics:

Every robot has a name (string), a battery level (integer, 0 to 100), and an operational status (one of: “standby”, “active”, “low_battery”, “offline”).
A robot’s battery level must always be between 0 and 100 inclusive. Setting it outside this range is an error.
A robot cannot perform a search if its status is not “active”.
When a robot’s battery drops below 20%, its status automatically changes to “low_battery”.
When a robot’s battery reaches 0%, its status automatically changes to “offline”.
A robot can be recharged, which sets its battery to 100% and its status to “standby”.
Every robot carries a sensor payload that it owns. The sensor payload is created when the robot is created and cannot exist independently. If the robot is destroyed, so is its payload.

Sensor Payload

A sensor payload represents the suite of instruments a robot carries. Every payload has a weight (in kg, must be positive) and a list of instrument names (e.g., [“thermal camera”, “lidar”]). The payload provides a method to check whether it contains a specific instrument.

Sectors

A sector represents a region of the disaster zone that must be searched. Each sector has:

A sector ID (string, e.g., “S-01”)
A terrain type (string, e.g., “urban”, “forest”, “flood”, “rubble”)
A hazard level (integer, 1 to 5, where 5 is the most dangerous)
A search difficulty value (float, 1.0 to 10.0, representing how hard the sector is to search)
A flag indicating whether the sector has been searched (initially False)
Sectors with terrain “urban” or “forest” have a required search altitude (float, in meters) for aerial operations. Other sectors have this set to None.

A sector cannot be assigned to a robot if the sector has already been searched. A sector’s hazard level must be between 1 and 5 inclusive.

Missions

A mission represents a single assignment of a robot to a sector. Each mission records:

The robot assigned (association: neither the mission nor the robot owns the other)
The sector being searched (association: neither the mission nor the sector owns the other)
The mission status (one of: “pending”, “in_progress”, “completed”, “failed”)
A result string (initially empty, populated when the mission completes)

When a mission is executed:

The robot’s status must be “active”; otherwise the mission fails immediately.
The robot must be compatible with the sector (robot.can_search(sector)); otherwise the mission fails.
The sector must not have been searched already; otherwise the mission fails.
The mission status changes to “in_progress”.
The robot performs the search (robot.search(sector)), which drains battery and produces a result.
If the robot’s battery dropped below 20% during the search, the mission fails.
Otherwise, the sector is marked as searched, the result is recorded, and the mission is completed.

Disaster Zone

The disaster zone manages the overall operation. It maintains:

A collection of sectors (aggregation: the zone manages sectors, but sectors could exist independently).
A collection of robots (aggregation: the zone manages robots, but robots could exist independently).

The disaster zone provides methods to add robots and sectors, query available robots and unsearched sectors, and generate a status report.

Suggested Timeline

This assignment is designed to be completed over 3 weeks. The following timeline is a suggestion to help you pace your work.

Period	Duration	Tasks
Week 1	Days 1–3	Read the use case carefully. Draw the UML class diagram on paper or using a tool. Identify all classes, attributes, methods, relationships, and multiplicity. Finalize `design_document.pdf`.
Week 1–2	Days 4–7	Implement and test `SensorPayload` and `Sector` (the two simplest classes with no dependencies on other custom classes). Write tests in each module’s `if __name__ == "__main__"` block.
Week 2	Days 8–12	Implement and test the `Robot` abstract base class and the two subclasses (`AerialDrone`, `GroundCrawler`). This is the most complex part. Focus on property validation, automatic status triggers, and the polymorphic `search()` and `can_search()` methods.
Week 2–3	Days 13–16	Implement and test `Mission` (focus on the 7-step `execute()` logic) and `DisasterZone` (aggregation, query methods, report generation).
Week 3	Days 17–19	Implement `main.py`. Wire everything together and demonstrate all OOP concepts (polymorphism, sorting, `__contains__`, report).
Week 3	Days 20–21	Code quality pass: add/review docstrings, type hints, and inline comments. Test the full program end to end. Package and submit.

Tip

Do not leave the Robot hierarchy for the last week. It is the most complex part and will take the most debugging time. Start it no later than Day 8.

Project Structure

Your submission must follow the directory structure shown below. Replace firstname_lastname with your actual name in lowercase (e.g., john_doe_rwa2).

firstname_lastname_rwa2/
|-- design_document.pdf     # Phase 1: UML class diagram
|-- sensor_payload.py       # SensorPayload class
|-- robot.py                # Robot base class, AerialDrone, GroundCrawler
|-- sector.py               # Sector class
|-- mission.py              # Mission class
|-- disaster_zone.py        # DisasterZone class
|-- main.py                 # Main program (entry point)

File	Description
`design_document.pdf`	Phase 1 deliverable: UML class diagram.
`sensor_payload.py`	`SensorPayload` class (composition target, owned by `Robot`).
`robot.py`	`Robot` abstract base class, `AerialDrone` subclass, `GroundCrawler` subclass.
`sector.py`	`Sector` class representing a region of the disaster zone.
`mission.py`	`Mission` class linking a robot to a sector (association).
`disaster_zone.py`	`DisasterZone` class managing robots and sectors (aggregation).
`main.py`	Entry point. Creates entities, runs missions, demonstrates all OOP concepts.

Phase 1: Design Document (6 pts)#

Phase 2: Implementation (44 pts)#

Part 2: Robot Base Class and Subclasses (16 pts)

Module: robot.py

Implement the Robot abstract base class and two concrete subclasses: AerialDrone and GroundCrawler.

Robot (Abstract Base Class) – 10 pts

__init__(self, name: str, battery: int, payload: SensorPayload)
- _name: non-public (read-only property)
- _battery: non-public, validated via property (0 to 100 inclusive, raise ValueError otherwise)
- _status: non-public, initialized to "standby"
- _payload: non-public (composition: the robot owns this payload)
Properties:
- name (read-only)
- battery (getter and setter): setter validates range and triggers automatic status changes:
  - If battery drops below 20, set status to "low_battery"
  - If battery reaches 0, set status to "offline"
- status (getter and setter): setter validates that the value is one of "standby", "active", "low_battery", "offline" (raise ValueError otherwise)
- payload (read-only): returns the SensorPayload object
Methods:
- activate(self) -> None: sets status to "active" if battery >= 20, otherwise raises RuntimeError
- recharge(self) -> None: sets battery to 100 and status to "standby"
- search(self, sector: Sector) -> str: abstract method (use abc.abstractmethod). Each subclass implements this differently. Returns a result string.
- can_search(self, sector: Sector) -> bool: abstract method. Returns whether this robot is compatible with the given sector.
Dunder methods:
- __str__: returns "<n> [<status>] (Battery: <battery>%)"
- __repr__: returns "<ClassName>('<n>', <battery>)"
- __eq__: two robots are equal if they have the same name
- __lt__: compares robots by battery level (enables sorting)

Important

Robot must inherit from abc.ABC and declare search and can_search as abstract methods. Attempting to instantiate Robot directly must raise TypeError.

AerialDrone – 3 pts

__init__(self, name: str, battery: int, payload: SensorPayload, max_altitude: float)
- _max_altitude: non-public (read-only property, must be positive)
Overrides:
- can_search(self, sector): returns True if the sector has a required_altitude that is not None and required_altitude <= max_altitude. Returns False otherwise.
- search(self, sector): drains battery by 5%, performs an aerial sweep, and returns "Aerial sweep of <sector_id>: covered <X>% of area" where <X> is computed as max(10, int(100 - sector.search_difficulty * 8)).

GroundCrawler – 3 pts

__init__(self, name: str, battery: int, payload: SensorPayload, max_speed: float, terrain_capabilities: list[str])
- _max_speed: non-public (read-only property, must be positive)
- _terrain_capabilities: non-public (read-only property)
Overrides:
- can_search(self, sector): returns True if the sector’s terrain type is in the crawler’s terrain_capabilities.
- search(self, sector): drains battery by 8%, performs a ground sweep, and returns "Ground sweep of <sector_id>: located <N> survivors" where <N> is computed as max(0, int(10 - sector.search_difficulty * 1.5)).

Part 6: Main Program (9 pts)

Module: main.py

Create a main() function that demonstrates all OOP concepts. Call it from an if __name__ == "__main__" guard. All program logic must live inside main().

The main() function must:

Create a DisasterZone with a descriptive name (e.g., "Hurricane Delta Response").
Create at least 4 sectors with a mix of terrain types. At least 2 should have a required_altitude value (for aerial drones) and at least 2 should have terrain types suitable for ground crawlers. Use different hazard levels and search difficulties.
Create at least 3 robots: at least 1 AerialDrone and at least 1 GroundCrawler. Give each a SensorPayload with different instruments and weights.
Add all sectors and robots to the disaster zone.
Activate all robots.
Create and execute at least 4 missions, including:
- At least one successful aerial drone mission
- At least one successful ground crawler mission
- At least one failed mission (e.g., incompatible robot/sector pairing)
Demonstrate polymorphism: iterate over a list containing both drones and crawlers and call search() on each with an appropriate sector, printing the results to show that different robot types produce different output.
Demonstrate sorting: sort robots by battery level using sorted() (enabled by __lt__) and print the sorted list.
Demonstrate __contains__: use the in keyword to check if a robot name is in the disaster zone and if an instrument is in a payload. Print the results.
Print the disaster zone report using generate_report().

Grading, Submission, and Policies#

Grading Rubric

Component	Points	Criteria
Phase 1: Design Document	6
UML Class Diagram	6	All 7 classes present with attributes, methods, types, and visibility (2 pts). Abstract class and abstract methods correctly notated (1 pt). All relationships with correct UML notation: composition, aggregation, association, inheritance (2 pts). Multiplicity labels on all relationship lines (1 pt).
Phase 2: Implementation	44
Part 1: SensorPayload	3	Correct attributes with validation (1 pt). `__contains__` works correctly (1 pt). `__str__` and `__repr__` (1 pt).
Part 2: Robot Hierarchy	16	Abstract base class with `abc.ABC` and abstract methods (2 pts). Properties with validation and automatic status triggers (4 pts). Two subclasses with correct `can_search` logic (3 pts). Two subclasses with correct `search` implementation and drain rates (3 pts). `activate()` and `recharge()` (2 pts). Dunder methods: `__str__`, `__repr__`, `__eq__`, `__lt__` (2 pts).
Part 3: Sector	4	Correct attributes with validation (2 pts). Optional `required_altitude` handled correctly (1 pt). Dunder methods (1 pt).
Part 4: Mission	6	`execute()` follows the 7-step logic correctly (4 pts). Handles all failure cases (1 pt). Dunder methods (1 pt).
Part 5: DisasterZone	6	Add methods with duplicate checks (1 pt). Query methods for available robots and unsearched sectors (1 pt). `generate_report()` with correct format (2 pts). `__len__`, `__contains__`, `__str__` (2 pts).
Part 6: Main Program	9	Creates required entities and adds to zone (1 pt). Executes 4+ missions including at least one failure (2 pts). Demonstrates polymorphism with a loop over mixed robot types (2 pts). Demonstrates sorting by battery and `__contains__` (2 pts). Prints disaster zone report (2 pts).
TOTAL	50

RWA 2: Search and Rescue Mission Planner#

Overview#

Phase 1: Design Document (6 pts)#

Phase 2: Implementation (44 pts)#

Grading, Submission, and Policies#

This Page