Essentials

• Keep repo simple: src/ (code), hw/ (wiring/parts), docs/ (README, notes)
• Decide roles: coordinator, software, hardware, tester (people can wear two hats)
• Meet 2–3x/week; write tasks; small commits; peer review by 1 teammate
• Test on bench often; demo weekly; log what worked/what broke

Not required for final project

• CI/CD pipelines, HIL/SIL rigs, ROS/Gazebo/Webots
• Formal RACI, CODEOWNERS, ADRs, devcontainers, feature flags
• Review SLAs, branching strategies beyond basic git
• Production observability dashboards, SLAs/SLOs

Curious? See appendix for real‑world extras.

Complexity & coupling

• Many moving parts: hardware, firmware, software, data, infra
• Hidden dependencies and integration risk grow non-linearly
• Real-time and safety constraints for sensing, compute, and actuation
• Unknown unknowns; requirements shift with discoveries

Precision & reproducibility

• Builds, environments, datasets must be reproducible
• Versioning: code, APIs, interfaces, CAD/BOM, experiments
• Safety, reliability, compliance constraints

Common roles (ENG100)

• People can wear multiple hats; rotate to learn
• Make ownership clear

Who does what?

• Coordinator: keeps tasks moving, runs meetings
• Software/Firmware: implements features, reviews peers
• Hardware: wiring, parts, safety (E‑stop), assembly
• Testing: writes a simple test checklist and runs it

Before starting

• Agree on acceptance criteria
• Identify dependencies; split into small tasks
• Aim for a demoable slice

Definition of Done

• Works on bench or in a simple demo
• Code pushed to main with one peer review
• README/notes updated

Cadence

• Short standups; weekly demo; quick retro
• Small PRs; avoid long branches
• Use a shared task board (Issues or a doc)

Risk

• List top 3 risks; prototype risky parts early

Structure (ENG100)

• src/: code and sketches
• hw/: wiring diagram and parts list (BOM)
• docs/: README, notes, design, photos
• tools/: optional helper scripts

Tooling

• Recommended try Git; create small branches; get one peer review
• Can use Google drive instead
• Maintain a manual test checklist; simple logging/plots if helpful
• Optional: a linter/formatter and a simple build script

Slice vertically

• Deliver end-to-end slices: sensing → compute → actuation → safety
• Each slice demonstrable on bench or sim; reduces integration risk
• Define interfaces & test points early (pins, message formats, expected ranges)

Estimate for decisions

• T-shirt sizes or points; track capacity, not precision
• Timebox spikes for unknowns; prototype high-risk parts

Prioritize by risk and value

• Front-load high-risk items and external dependencies
• Account for lead times (PCBs, sensors, machining); plan parallel work
• Include calibration and test fixtures in scope
• Maintain a living roadmap and definition of done

Interfaces & timing

• Clear pinouts, message formats, and expected rates
• Record timestamps in logs; be aware of delays
• Simple sensor calibration steps (write them down)

Power & safety

• Power budget, fuses, connectors, and strain relief
• Basic cable management; avoid noise near signal wires
• Safety: E-stop and fail-safe defaults

Dev workflow

• Pick a task → small branch → small PR → quick peer review → merge → flash/test
• Use a simple bring-up checklist; keep safe defaults
• Log what you tried and the result

Verification

• Bench tests with simple fixtures or simulated inputs
• Short, supervised field tests with safety in place
• Record basic logs for debugging; replay when helpful

Scaffold

• Repo initialized; README with getting started, architecture sketch, wiring diagram
• Basic task list with owners and due dates
• hw/: BOM started; long-lead parts identified
• Simple build/flash instructions checked by a teammate

Team & plan

• Working agreements written (peer review, demo cadence)
• MVP defined; top 3 risks identified; long-lead orders placed
• Bench test checklist; safety checklist and E-stop procedure
• Backlog of 5–10 thin slices ready; demo/retro on calendar