Oct 12 Meeting Log - snuhcs-course/swpp-2026-project-team-18 GitHub Wiki

Agenda: Iteration 2 planning: learning algorithm, data collection, and task assignment

Role assignment & schedule
- Frontend work continues on the front-iter2 branch (김진호), backend work on the back-iter2 branch (박준하).
- Research needed to explore ways to make broader use of device sensors.
Learning algorithm
- Cold start (no learned data yet)
  - Use a daily total-preparation statistic (mean and standard deviation of each day's records) as the default for users without block data.
  - When even that is unavailable, compute from the values the user entered at sign-up. The app will not show a "learning in progress" message.
  - Per-block data collection was considered but set aside for this iteration. Asking users to enter an accurate preparation time for every block would be tedious, which conflicts with the app’s main purpose: sparing users the effort of calculating and setting their own alarms.
- What the model learns
  - Total preparation time (instead of per-block learning), route travel-time correction (actual vs. Kakao prediction), and the buffer.
  - The buffer is currently a fixed value and also needs to be learned. The "how much slower preparation gets when there is plenty of slack" value is collected but not yet read by the model.
  - Keep the current approach: compute each user's mean, standard deviation and count directly from the DB, weight measured values against configured values, and adjust according to tau.
- Travel-time learning: derive a single multiplier from collected Kakao data and apply it, with fallback levels:
  1. Same route + same time slot + weekday/weekend
  2. Same route + weekday/weekend
  3. Any route, same transport mode (e.g., all public transport)
  4. All trips
  - With fewer than 3 records on a route, levels 1 and 2 are skipped and levels 3 and 4 (pooled across all users) are used instead, e.g., "public transport usually takes 1.1x the prediction, ±4 min".
- train_models is never run automatically. It must be scheduled to run daily at 03:00, as the spec states.
- Check that data is accumulating properly. Collect data every day, whether the trip succeeds or fails.
Preparation blocks
- Open question: learn per block and sum (current behavior), or learn the total and adjust the proportions within blocks. Note that the Bayesian update function is currently never called.
- Missed taps: skipping a block makes the next block count from alarm dismissal, and a late tap records an overly long block. _ * Splitting preparation into blocks on screen, and entering the segmented routine at sign-up, were set aside for this iteration._
- Move app-side calculations to the server
Real-time updates
- Real-time updates while traveling need careful checking, especially without mobile data. It is unclear whether failures come from GPS or from the lack of data; the feature should work without data too.
- Found a bug where arrival is not always recorded correctly. The cause needs a closer look, through both a code review and hands-on usability testing.
Report feature (LLM integration)
- Check if the available APIs were given by the TAs.
- If given, start this feature implementation in this iteration.
Frontend tasks (김진호, front-iter2)
- Walking and bicycle show a single route. Tapping it should open the map screen.
- Check and update the frontend for backend changes.
- Simplify the "+5 min" style UI, which shows too much information.
- Change the "travel variability appears after traveling the same route several times" message to match actual behavior, or do not show that message to the user.
- Remove the "learning in progress" message.
- Display learned values wherever they are available.
- Implement the report screen.
Backend tasks (박준하, back-iter2)
- Continue the previously requested tasks B8–B23.
- Reset alarm toggle history when a new alarm is added: only the first alarm of the day turns on and the rest turn off, regardless of earlier manual toggles.
- Simplify arrival detection: drop the "two consecutive fixes, stay 2 minutes" rule (currently within 50 m) and widen the geofence so entering it marks arrival immediately.
  - Suspected causes of missed arrivals to check:
    1. Tracking starts only when "Dismiss" is pressed on the alarm screen, and there is no manual arrival.
    2. Arrival state lives only in memory, so it is lost when the app restarts, and the server record is not re-read.
    3. The 2-minute stay plus discarding fixes with accuracy worse than 50 m can leave indoor or large-building users stuck on "checking arrival".
    4. A single 404 in a batch makes the app clear the whole observation queue, which may have dropped valid arrival records after switching from the local to the deployed server.
- Support more calendar sources (Android's built-in calendar, Google Calendar, etc.).
- Verify data is accumulating and models are training.
- Schedule train_models to run daily at 03:00, and confirm the buffer is being learned (implement it if not).
- Implement the report feature (LLM integration).
Backend TODO status
- Done (local main): alarm on/off and first-alarm-of-the-day rule (BE-1–3), password validation, check API and terms storage (BE-4–6), transit badges and alternative bus numbers (BE-9, 10), walking steps and kcal (BE-13), lateness sensitivity (BE-15), risk selection storage and alarm recalculation (BE-17), same origin/destination validation (BE-19), walking/bicycle candidate route map (BE-23), missing prep routine when departing from home, arrival state persistence, local E2E after front-iter1 integration, and full E2E on the shared server (previous main).
- Remaining: route candidates by mode (BE-7), four car candidates (BE-8), departure/arrival times matched to the arrival target (BE-11), route guidance text (BE-12), bike-lane ratio (BE-14, optional), risk options and distribution API (BE-16), home as destination (BE-18), recurring events (BE-20), custom event tags (BE-21, later), sleep time (BE-22, pending team decision).