Role: Sensor Fusion / Navigation / ML Co-Builder

Phase: 2–3 — Hardware Prototype and Cloud MVP Engagement type: Co-builder, with a meaningful stake in what we build and terms worked out together Scope estimate: Open-ended research and development; first milestone ~80–150 hours When to engage: Now, in parallel with the firmware/hardware co-builder (role 3) Status: Seeking

Why This Role Matters

Removing GPS, cellular, and equipment tags made the hardware simple and durable. It moved the hard problem into algorithms. Someone has to turn a day of inertial and barometric data into:

  • The driving route, matched to real roads
  • Every stop, matched to a known customer site or flagged as unscheduled
  • The walking path across each property
  • A trustworthy split of labor by type

That is the core technical risk of Actual. If closed-loop inertial navigation plus road and elevation map matching can’t find job sites reliably, the concept needs to change. This role finds out, and then makes it work.

The Problem

See cloud-architecture.md.

  • Closed loop: every shift starts and ends at the shop, a known point. Stops are zero-velocity updates. Forward-backward smoothing spreads the closing error across the day.
  • Map matching: IMU turn sequences and distances, plus a barometric elevation profile, scored against a road graph (OpenStreetMap) and terrain model (USGS 3DEP). HMM or particle-filter style.
  • Priors: the day’s schedule and the crew’s past routes narrow the search.
  • Pedestrian dead reckoning on properties, constrained to parcel boundaries.
  • Activity recognition: on-device models (with role 3) and cloud cross-checks.

Open questions this role owns:

  • How much raw data is needed versus on-device summaries
  • Achievable stop and site-match accuracy in flat, grid-street areas
  • Whether the magnetometer helps or hurts near trucks and engines
  • How to express confidence honestly to the business owner

Technical Requirements

  • Inertial navigation and sensor fusion (Kalman / RTS smoothing, factor graphs)
  • Map matching (HMM-based or similar) and working with road graphs
  • Python scientific stack; comfortable shipping code that runs unattended
  • Time-series ML for activity recognition; ideally some TinyML experience
  • Pedestrian dead reckoning is a strong plus

Deliverables

Milestone 1 — Feasibility

  • Record test shifts with a prototype or dev-kit IMU + barometer, plus a reference GPS logger for ground truth
  • Reconstruct routes and stops offline
  • Report: stop detection rate, site-match accuracy, and failure cases. Honest numbers.

Milestone 2 — Pipeline v0

  • Reconstruction stages implemented as a versioned Python package
  • Regression suite of recorded shifts with ground truth, scored automatically
  • Activity classifier v0 for the badge (with role 3)

Milestone 3 — Field-ready

  • Confidence scoring that the dashboard can display
  • Tuned on industry partner recordings

Where to Find

  • Robotics and autonomous-vehicle localization communities; ROS Discourse
  • Indoor positioning and PDR research (IPIN conference authors)
  • Georgia Tech robotics (IRIM) and aerospace alumni
  • Authors of open-source map-matching or inertial-odometry projects on GitHub

Vetting

  1. Walk through how they would reconstruct a 40-km day of driving from IMU and barometer alone, given known start and end points.
  2. Where would they expect the method to fail, and how would they detect that it had?
  3. How would they build ground truth cheaply?
  4. Code sample: a filtering, SLAM, or map-matching project.

The right candidate is skeptical, asks about sample rates and mounting, and wants to see data before promising accuracy.

Known Risks

Risk: Accuracy isn’t good enough in some terrain. Mitigation: Measure early (Milestone 1). Use schedule and history priors. Report confidence rather than forcing answers. If needed, revisit the architecture honestly and early.

Risk: Algorithms work offline but are too expensive to run per shift. Mitigation: Track compute per shift from Milestone 2 on.