RunPacer: Vibrotactile Co-Running System
- RunPacer is a pacing research system that uses vibrotactile feedback to achieve symmetric, non-verbal cadence synchronization between runners.
- It eliminates the need for verbal cues or physical tethers, reducing cognitive load and improving natural rhythm coordination.
- The approach extends across assistive technology, elite marathon pacing, and urban route recommendations, highlighting its multifaceted applications.
Searching arXiv for RunPacer and closely related pacing/co-running systems to ground the article in current literature. arxiv_search(query="RunPacer smartwatch vibrotactile feedback symmetric co-running visually impaired guides", max_results=10, sort_by="relevance") arxiv_search(query="Snoopie pacerbot runner interval training quadruped arXiv", max_results=10, sort_by="relevance") arxiv_search(query="Against negative splitting elite marathon pacers official events arXiv", max_results=10, sort_by="relevance") RunPacer denotes a cluster of pacing-oriented research systems concerned with how runners coordinate movement, select routes, and externalize pace. In its primary and most explicit usage, RunPacer is a smartwatch-based vibrotactile feedback system for symmetric co-running by visually impaired individuals and guides, delivering synchronized rhythmic pulses to both runners so that interpersonal cadence alignment becomes the core interaction model rather than continuous verbal communication or mechanical tethering (Yu et al., 6 Jul 2025). In adjacent work, the same label is also used for a fieldable pacing-with-pacer workflow for elite marathon athletes, a personalized running-route recommender based on sensory mapping in urban environments, and a RunPacer-style optimal-control algorithm for fixed-distance pacing (Fernandes et al., 2023, Hänsel et al., 9 May 2025, Aftalion et al., 2020).
1. Conceptual scope and design rationale
RunPacer, in the smartwatch-based assistive sense, was introduced to address a specific limitation in guide running for visually impaired individuals. Verbal cues require constant attention to spoken instructions such as “left,” “speed up,” and “slow down,” and are described as mentally fatiguing and unreliable in noisy outdoor environments. They also introduce latency: the guide speaks, the runner processes, and the runner adjusts, by which time the guide may already have changed pace or direction. Physical tethers, by contrast, restrict natural arm swing and stride length, leading to discomfort and an altered running gait, and reinforce a unidirectional dependency in which the guide “drives” the run and the visually impaired runner passively follows (Yu et al., 6 Jul 2025).
Against that background, RunPacer defines its central problem as interpersonal rhythm coordination. It leverages entrainment theory, namely the premise that humans naturally sync their movements to an external rhythm, and therefore provides identical haptic pulses to both guide and runner so that neither is relegated solely to leading or following. The stated goals are accessibility and autonomy: eliminating the need for speech or mechanical connection, while fostering safety, comfort, and social engagement.
A common misconception is to place RunPacer in the same category as assistive systems centered on navigation or obstacle avoidance. The co-running system is positioned differently: its stated focus is shared rhythm rather than spatial navigation. This distinction matters because the interaction primitive is cadence synchronization, not turn-by-turn control.
2. Hardware platform and software pipeline
The hardware platform described for RunPacer is the Apple Watch Series 7. Its sensing stack uses an Inertial Measurement Unit, with accelerometer sampling at approximately and gyroscope sampling at approximately , both configurable via Core Motion. Vibrotactile output is delivered through the Taptic Engine, with moderate maximum vibration intensity, single-tap pulses, and a pulse duration range of $100$–. Inter-device communication uses Bluetooth Low Energy for sub- round-trip latency (Yu et al., 6 Jul 2025).
The software pipeline is organized into five modules. IMU Data Acquisition pulls raw accelerometer and gyroscope frames at . Signal Processing and Step Detection applies a band-pass filter from $0.5$ to to isolate running frequencies, then identifies vertical-acceleration peaks corresponding to foot-strikes. Cadence Estimation and Smoothing timestamps each detected step, computes inter-step intervals, and derives cadence estimates. The Shared Cadence Engine supports two modes: Static Preset Mode, which uses a user-configured target step frequency, and Adaptive Mode, which mirrors the guide’s smoothed cadence. Vibrotactile Feedback Delivery triggers the Taptic Engine on reception of each beat packet.
In block-diagram form, the sequence is:
IMU band-pass filter peak detector 0 cadence estimator 1 smoother 2 Shared Cadence Engine 3 BLE transceiver 4 remote watch 5 vibrotactile actuator.
This architecture suggests that RunPacer treats cadence extraction, inter-device synchronization, and haptic rendering as separable layers. A plausible implication is that multimodal extensions can be inserted at the cadence-engine stage without changing the step-detection front end.
3. Cadence estimation, adaptation, and pulse scheduling
RunPacer’s pacing logic is formulated in terms of cadence rather than speed. If 6 denotes the inter-step interval, the instantaneous cadence is
7
To reduce short-term variability, the guide cadence is smoothed by exponential smoothing:
8
with 9 (Yu et al., 6 Jul 2025).
The Shared Cadence Engine then operates in one of two modes. In Static Preset Mode, the system uses a target cadence $100$0, for example $100$1. In Adaptive Mode, it mirrors the guide’s smoothed cadence. The adaptive update rule is
$100$2
where $100$3, with $100$4 exemplified as $100$5. Initialization is $100$6 or the first detected $100$7. For BLE broadcasting, the system packages timestamped cadence in $100$8 UDP-like packets.
Pulse scheduling is then derived directly from adapted cadence. With pulse width $100$9, tunable over 0–1, the inter-pulse interval is
2
Each watch schedules a haptic pulse of duration 3 every 4. Because both watches receive identical rhythmic structure, the interaction is explicitly bidirectional and symmetric rather than leader-follower.
This cadence-centered formulation differentiates RunPacer from pace displays or waypoint systems. It does not instruct runners through semantic messages; instead it enforces a shared temporal scaffold.
4. Empirical evaluation in co-running
The reported user study used 5 pairs, for 6 participants in total, with one blindfolded runner and one sighted guide in each pair. The course was a straight 7 outdoor track. The experimental condition was RunPacer-only, with no speech and no tether. Quantitative measures were synchronization accuracy, defined as the time difference between guide and runner foot-strikes via footpods, and a subjective questionnaire on a 8-point Likert scale covering ease of synchronization, clarity of vibration, comfort, perceived safety, and mental or cognitive load relative to verbal cues (Yu et al., 6 Jul 2025).
| Metric | Mean | SD |
|---|---|---|
| Mean absolute asynchrony | 48 ms | 15 ms |
| Phase-locking index (0–1) | 0.87 | 0.05 |
| Question | Mean | SD |
|---|---|---|
| Ease of synchronization | 4.4 | 0.5 |
| Clarity of vibration | 4.2 | 0.6 |
| Comfort | 4.6 | 0.4 |
| Perceived safety | 4.5 | 0.5 |
| Reduced cognitive load | 4.7 | 0.3 |
Qualitative feedback emphasized naturalness and low attentional burden. One participant statement was: “Felt natural—even without looking or listening, I stayed in step.” Requests included adjustable intensity when running faster and optional subtle audio beats for complex terrain.
These results support the narrow claim that synchronized vibrotactile cadence cues can sustain co-running symmetry on a controlled outdoor course without verbal instructions or tethering. They do not, by themselves, establish performance across varied terrains or dense urban traffic. That broader deployment remains a stated future direction rather than a reported result.
5. Broader uses of the RunPacer label in pacing and route computation
The name RunPacer also appears in adjacent research as a label for analytical or software systems that are not the same as the smartwatch co-running platform. In marathon pacing, Fernandes and Maldonado describe how findings from a metabolic-power model coupled with CFD-derived drag curves can be translated into a fieldable pacing-with-pacer system, explicitly called “RunPacer.” Their framework divides the marathon into a protected phase, in which the main runner drafts 9 behind a pacer, and an unprotected phase run solo. For the case 0, the optimal protected speed is 1, the corresponding unprotected speed is 2, and the ratio 3–4, implying that the protected phase should be run 5–6 faster than the unprotected phase. The paper concludes that, when at least one pacer is present, positive splitting is the best pacing strategy and yields significant time savings in official marathon events (Fernandes et al., 2023).
A second usage appears in urban route recommendation. A technical blueprint for RunPacer, inspired by research on the experience of running, defines a personalized running-route recommender based on sensory mapping. It integrates Flickr geo-referenced pictures and tags, OpenStreetMap attributes, and official crime data; normalizes segment-level features such as smellscapes, soundscapes, beauty, obstacles, traffic, and safety; extracts three principal components from runner-experience survey data—Performance & Achievement, Perceived Environment, and Mind & Social Connectedness—and then clusters route preferences into Scenic and Urban profiles by 7-means with 8. Route generation is performed in a weighted street graph using GraphHopper with A* search, and the reported real-time constraint is that A* on tens of thousands of segments runs in under 9 on a mid-range server (Hänsel et al., 9 May 2025).
A third usage is methodological. In work on pace and motor control optimization, a RunPacer-style algorithm is constructed from an optimal-control model with state variables for distance 0, speed 1, propulsive force 2, remaining anaerobic energy 3, and neural drive 4. The objective is
5
with dynamics that include 6, 7, 8, and 9. For long races, the central behavior is described as a turnpike, with short start and finish layers around a near-constant equilibrium. This usage makes RunPacer a computational pacing planner rather than a wearable system (Aftalion et al., 2020).
Taken together, these variants show that RunPacer is not a single monolithic framework. The literature uses the term for several systems that share a concern with pacing, coordination, or route optimization but differ in modality, mathematics, and deployment context.
6. Relation to positive-split theory and embodied pacers
The broader pacing literature connected to RunPacer includes both analytical arguments for positive splitting and embodied trainer systems. Reardon’s “X-factor” model for $0.5$0 and $0.5$1 races formalizes anaerobic buildup through
$0.5$2
and derives a two-phase optimum consisting of maximal acceleration from rest followed by exponential decay in speed. For any $0.5$3 in the power-law form $0.5$4, the optimal pacing in the deceleration-limited phase is monotonically decreasing, which the summary interprets as positive splits. The suggested practical implication is to display target split times that are $0.5$5–$0.5$6 faster than even pace in the first half and then gently decelerate (Reardon, 2012).
A distinct but related line of work appears in SNOOPIE, an autonomous robot quadruped pacer for interval training. Built on a Unitree Go2, SNOOPIE uses a control hierarchy with a low-level gait controller $0.5$7 and a high-level navigation and pacing policy $0.5$8. Track-line centering is handled by a PID angular controller, while forward speed alternates between $0.5$9 and 0 after a brief calibration phase using an ArUco marker worn by the runner. In a within-subjects study with 1 novice runners, the quadruped trainer achieved a 2 reduction in average pace error compared to the Apple Watch and a 3 reduction in within-interval speed variance, while subjective ratings favored the robot on ease of use, enjoyability, and helpfulness (Du et al., 20 Apr 2026).
These neighboring results clarify the place of RunPacer within a wider taxonomy of pacing systems. The smartwatch RunPacer emphasizes non-visual, symmetric entrainment; the marathon RunPacer emphasizes drafting-aware split optimization; the route-recommender RunPacer emphasizes sensory preference and graph search; and SNOOPIE emphasizes embodied visual pacing. This suggests that “RunPacer” functions less as the name of a single canonical product than as a recurring research motif for externalizing pace in ways that reduce cognitive load, alter coordination structure, or personalize the running experience.
The future directions named for the smartwatch RunPacer are multimodal feedback, physiological adaptation, group running via BLE mesh with a common “beat-bus,” deployment with visually impaired running clubs across varied terrains, and publication of an open SDK for multisensory co-locomotion experiences (Yu et al., 6 Jul 2025). Across the broader literature, a plausible implication is that future RunPacer systems will continue to hybridize sensing, personalization, and external pacing cues, while remaining differentiated by whether they optimize rhythm, route, or embodiment.