Shaaf Kashan

SWIFTBOT

First-year group project: robotics & software engineering in Java

We designed the robot task as flowcharts and pseudocode before writing any Java, so logic gaps were caught on paper and the robot was demonstrated live in a viva.

The principle: Agree the logic in a reviewable form first, while a mistake is still cheap to fix.

Graded A.

In brief

  • Challenge: Taking a robot task from requirements through design to a working Java implementation as a group.
  • Outcome: A working robot task in Java, demonstrated live in a viva, with the full process documented across the team.

Context

A first-year team software-engineering project built on a SwiftBot — a Raspberry Pi robot with buttons, LEDs, and sensors. The brief was to take a robot task from requirements through design to a working Java implementation as a group, treating software engineering as more than just coding: requirements, design, teamwork, testing, and a live demonstration.

Constraints

  • Real robot hardware (buttons, LEDs, and sensors) meant the program had to handle physical input and timing, not just abstract logic.
  • A multi-person team with distinct roles — analyst, designer, programmer, tester — had to coordinate through a defined process rather than ad-hoc coding.
  • As a first-year module, the work had to demonstrate the full software-engineering lifecycle end to end within fixed assessment gates: a design report, then an implementation with a viva.

Decisions

  • Designed the robot task up front as flowcharts and pseudocode before writing any Java, so the logic was agreed and reviewable before implementation.
  • Used object-oriented decomposition in Java to separate input handling, task logic, and output into clear, independently testable units.
  • Split the team into defined software-engineering roles and tracked progress as a group, mirroring how real projects coordinate across people.

Trade-offs

  • Designing fully before coding added overhead, but caught logic gaps early — far cheaper to fix on paper than on the robot.
  • Group coordination was slower than working solo, but that was the point of the module: practising the communication and process real software teams run on.

Outcome

Delivered a working robot task implemented in Java and demonstrated live in a viva, with the full software-engineering process — requirements, design, implementation, and testing — documented across the team.

Evidence

  • Working Java implementation demonstrated live to markers in a viva.
  • Object-oriented design with input, task logic, and output separated into independently testable units.
  • Graded A.

Stack

  • Java
  • OOP
  • Raspberry Pi
  • Git
  • Agile

Architecture

  • Input: Buttons & Sensors (Hardware) — Physical input from the SwiftBot robot
  • Logic: Task Logic (Java) — Object-oriented robot-task logic
  • Output: LEDs & Motors (Hardware) — Robot responses and feedback