Puffin

Team USMNT · CS160 design case study

Puffin bird logo Puffin

A browser interface
for drone simulation.

Puffin integrates simulation launch, monitoring, control, and diagnostics across Docker, PX4, Gazebo, and ROS.

View the implementation Open live prototype
simulation pipeline
01
Dockerenvironment
02
PX4flight stack
03
Gazebosimulation
04
ROS 2services + graph
One interfacevisible, controllable, connected
ResearchIdeationPrototypingBuildEvaluation

Project at a glance

Project scope

The project examined whether a browser interface could reduce setup barriers while retaining the technical information needed for robotics work.

01

The problem

Simulation setup crossed repositories, command-line tools, operating systems, and dependencies.

02

Who it serves

Drone developers, non-programming engineering teammates, and learners using simulation tools.

03

The response

A dashboard combining simulation controls, telemetry, process status, ROS views, and terminal access.

01Needfinding
02Ideation
03Lo-fi
04Hi-fi
05Build
06Evaluate

Discover · Needfinding

Needfinding identified setup and coordination barriers.

Four interviews covered programming, mechanical engineering, aerial photography, and hobbyist flying.

G

Glen

Programming lead

Setup crossed three repositories, Docker, VNC, and a Linux-native pipeline.

G

Greg

Mechanical team lead

Mechanical testing depended on programming-team handoffs.

H

Haskell

Aerial photographer

Pre-flight work combined airspace tools, inspection, and judgment.

B

Britt

FPV pilot + builder

Existing simulators supported practice but assumed prior knowledge.

Participant names are the pseudonyms used in the research report.

Evidence

Command-line dependence, cross-platform constraints, fragmented status, and team handoffs impeded setup and recovery.

Decision

Compare concepts addressing setup, pre-flight work, and behavior authoring before selecting a direction.

What changed

A simulator dashboard, pre-flight companion, and behavior library advanced to concept comparison.

Define + Explore

Concept selection prioritized the setup workflow.

The team generated eleven ideas and compared three concepts against the needfinding evidence.

Early sketch of a cross-platform simulation launcher that checks repositories and launches the simulator
Selected direction

Cross-platform simulation launcher

Addressed the multi-repository setup failure and the broadest user group.

Sketch exploring a natural-language console and voice-controlled drone commands
Alternative

Natural-language controls

Reduced command syntax but covered only one part of the workflow.

Sketch of a behavior marketplace and physical cards used to compose drone actions
Alternative

Behavior library + physical cards

Supported collaboration but introduced maintenance and scaling constraints.

Evidence

The dashboard addressed the observed setup failure and served the broadest user group.

Decision

Advance the cross-platform launcher over the narrower alternatives.

What changed

Launch, monitor, and recover became the tasks for two paper prototypes.

Lo-fi prototyping

Paper prototypes tested interface depth.

One prototype emphasized direct controls; the other emphasized terminal access, package uploads, and process detail.

01Configure + launch
02Monitor + control
03Diagnose + recover
Paper prototype of a simulation dashboard with a drone viewport, telemetry, controls, and emergency stop
Prototype 1 made the core flight workflow visible and directly controllable.
Paper prototype of a simulation startup failure screen with dependency checks and recovery actions
Plain-language checks explored how users could recover without an expert.
Paper prototype flow connecting login screens, a terminal-forward simulator, and process details
Prototype 2 kept advanced process details and terminal access close at hand.
Evidence

Three testers—a Programmer, Builder, and Beginner—preferred one interface. Beginners needed clear controls; experts requested logs, process state, and package access.

Decision

Use progressive depth instead of a beginner-only or terminal-first interface.

What changed

The hi-fi concepts paired a dashboard overview with technical information and advanced controls.

Hi-fi iteration

Hi-fi critique determined the implementation structure.

Three concepts were compared for visibility, learnability, safety, and information density.

Hi-fi direction one: a light dashboard with a wide viewport, telemetry, mission progress, and terminal
Direction 1Rich status + mission detail
Hi-fi direction two: a dark terminal-forward dashboard with telemetry and process health
Direction 2Dense, technical control
Hi-fi direction three: a modular dashboard with a navy sidebar, viewport, telemetry, logs, and service health
Direction 3 · chosenModular, familiar, layered
Evidence

Direction 3 provided the clearest modular overview. Critique identified unclear labels, unused space, and color-only state; participants valued ROS health for system checks.

Decision

Combine Direction 3’s structure, Direction 2’s controls, and Direction 1’s mission detail.

What changed

Implementation used a labeled sidebar, modular status cards, text-backed state, flight controls, and dedicated ROS views.

Build · Implementation

Implementation translated four design requirements into the interface.

The build integrated system visibility, direct control, progressive technical depth, and recovery support in one browser interface.

puffin · dashboard
Final Puffin dashboard showing a live Gazebo simulation, flight telemetry, vehicle controls, lifecycle nodes, and running simulation processes
Final dashboard Simulation, telemetry, controls, node state, and process health appear in one view.
Final Puffin ROS Nodes screen with lifecycle status, launch commands, and run or stop controls
Requirement 01 · Lifecycle visibility

Expose node state and controls.

The Nodes view identifies active nodes, their connections, launch commands, and run or stop actions.

Final Puffin ROS Graph screen showing nodes, topics, and publish or subscribe connections
Requirement 02 · System observability

Visualize ROS data flow.

The Graph view shows active nodes, topics, publishers, and subscribers without separate command-line inspection.

Requirement 03 · Direct control

Provide the complete flight workflow.

Users can start, stop, reset, arm, take off, and land while checking system state.

Requirement 04 · Progressive depth

Retain terminal access and telemetry.

The terminal supports expert workflows; telemetry provides readable feedback for all users.

29+automated backend tests documented in M4
3primary workflows prepared for end-to-end evaluation
1browser-based operational surface
Evidence

M4 testing confirmed core controls and live data paths; it did not measure whether users understood readiness and recovery.

Decision

Evaluate integrated tasks rather than isolated screens.

What changed

The study tested launch readiness, offboard-flight monitoring, and recovery from a stopped stack.

Evaluate · Five users

Evaluation found incomplete readiness guidance.

Five participants completed launch, monitoring, and troubleshooting scenarios. Measures included completion, time, interventions, and missing features.

4/5

completed takeoff

An 80% task completion rate.

216.8s

average successful takeoff

Successful users finished between 2:35 and 4:52.

1.8

average interventions

The participant who did not finish needed four.

Bar chart showing interviewer interventions and critical features identified as missing for each of five users
Every participant identified at least three missing critical features; intervention counts ranged from one to four.
Finding 01

Readiness needed one clear answer.

Participants checked several status areas to determine whether the system was ready.

Design implication

Centralize system health and recommended recovery actions.

Finding 02

Controls hid prerequisites.

Some users missed simulator, arming, or lifecycle prerequisites before takeoff.

Design implication

Guide pre-flight and explain unavailable actions.

Finding 03

Technical depth was valuable when users could act on it.

Experienced participants valued ROS Nodes and Graph information normally accessed through separate tools.

Design implication

Keep detailed views, with summaries and contextual guidance.

Evidence

Four of five users completed takeoff, but participants searched across status areas and missed prerequisites.

Decision

Retain ROS detail while prioritizing guidance, consolidated health, and recovery.

Next iteration · not yet built

Add guided pre-flight, lifecycle help, reset/reconnect, centralized health, GPS/map views, and joystick controls.