Time-Based Motion Control in LEGO SPIKE Prime: Theory, Practice, and Pedagogy

Introduction

Educational robotics often emphasizes position-based control—programming robots to move specific distances or turn precise angles. While this approach develops important mathematical skills and produces repeatable results, it represents only part of the robotics landscape. Many real-world applications, from manufacturing to entertainment to autonomous systems, rely heavily on time-based control paradigms where duration, rhythm, and synchronization matter as much as final position.

The LEGO SPIKE Prime move_for_time method introduces students to this alternative control philosophy, where commands specify “move with this steering for this duration” rather than “move until reaching this position.” This seemingly simple shift opens new possibilities: synchronized multi-robot performances, choreographed demonstrations timed to music, rapid path prototyping without complex calculations, and intuitive exploration of the fundamental physics relationship between time, velocity, and distance.

This comprehensive guide examines time-based motion control in educational robotics, exploring its theoretical foundations, practical applications, pedagogical advantages, and the appropriate contexts for choosing time-based over position-based approaches.

Background: Time-Based vs. Position-Based Control Paradigms

Understanding Control Paradigms

Robot motion control fundamentally answers the question: “When does the motion stop?” The answer defines the control paradigm:

Position-Based Control (move_for_degrees):

• Stopping Criterion: Motor reaches specified rotational position
• Feedback Loop: Motors report current position; continue until target achieved
• Result Consistency: Highly repeatable regardless of external factors
• Computation: Requires calculating degrees from desired distance/angle
• Use Cases: Precision navigation, competition routines, measured movements

Time-Based Control (move_for_time):

• Stopping Criterion: Specified time duration elapses
• Feedback Loop: Internal timer; stop when duration reached
• Result Consistency: Variable—depends on battery, friction, loading
• Computation: Direct duration specification; distance emerges from motion
• Use Cases: Choreography, approximate navigation, teaching kinematics, prototyping

Velocity-Based Control (move with manual stop):

• Stopping Criterion: Program explicitly issues stop command
• Feedback Loop: External (sensors, events, conditions)
• Result Consistency: Highly variable based on stopping logic
• Computation: Continuous evaluation of stopping conditions
• Use Cases: Sensor-responsive navigation, adaptive behaviors, exploration

The Mathematics of Timed Motion

Time-based motion involves straightforward kinematics. For straight-line motion (steering=0):

Distance = Velocity × Time

More precisely for LEGO SPIKE Prime:

Distance (cm) = (Velocity_Parameter / 100) × Max_Speed (cm/s) × Time (s)

Where Max_Speed depends on wheel size:

• Standard 5.6 cm wheel: ~24 cm/s at velocity=100
• Large 8.8 cm wheel: ~38 cm/s at velocity=100

Example: velocity=50, time=2 seconds, standard wheels:

Distance = (50/100) × 24 cm/s × 2s = 24 cm

Curved Path Complications

When steering≠0, the robot traces an arc. Arc length and turn angle become:

Turn_Rate (degrees/second) = f(steering, velocity, wheel_base)
Arc_Length = Linear_Speed × Time
Turn_Angle = Turn_Rate × Time

The function f() relating steering to turn rate is non-linear and robot-specific, requiring empirical calibration. This complexity is why visualization tools (LEGO SPIKE move_for_time Path Forecaster) prove so valuable—calculating predicted paths manually is prohibitively complex for educational settings.

Battery Voltage Sensitivity

Time-based commands exhibit significant voltage sensitivity. Motors don’t directly control speed; they control power (voltage) applied to coils. The same velocity parameter produces different actual speeds depending on battery voltage:

Fresh Battery (8.4V):

• Velocity=50 → ~12 cm/s actual speed
• 3-second movement → ~36 cm distance

Depleted Battery (7.2V):

• Velocity=50 → ~10 cm/s actual speed
• 3-second movement → ~30 cm distance

This 6 cm difference (17% variation) can determine success or failure in precision tasks. Position-based commands partially compensate through feedback control; time-based commands cannot.

Workflows: Implementing Time-Based Motion Effectively

Choreographed Performance Workflow

Step 1: Musical/Event Analysis

• Identify key timing marks in music or event sequence
• Determine total duration and segment boundaries
• Note tempo changes if synchronizing to music

Step 2: Movement Vocabulary Development

• Create library of basic movements with known durations:
  • “Forward dash”: 1.5s straight at velocity=70
  • “Spin”: 1.0s at steering=100, velocity=60
  • “Gentle curve”: 2.0s at steering=30, velocity=50
• Test and document each movement’s appearance and space requirements

Step 3: Sequence Composition

• Combine vocabulary movements to fill time segments
• Use visualization tools to preview paths fit performance space
• Maintain running total of elapsed time to verify sync

Step 4: Rehearsal and Refinement

• Test complete sequence, noting timing drift
• Adjust individual segment durations to maintain sync
• Add pauses (runloop.sleep_ms()) to hit critical timing marks

Step 5: Battery Management Protocol

• Establish minimum battery voltage for performances
• Test full routine at minimum voltage to verify still works
• Plan recharge schedule for multi-performance events

Rapid Prototyping Workflow

For quick exploration of navigation strategies without detailed calculations:

Step 1: Approximate Requirements

• “Need to go roughly 30 cm forward, then turn about 90°”
• No precise measurements yet

Step 2: Time-Based Estimation

• “30 cm at moderate speed probably takes 2-3 seconds”
• “90° turn probably takes 1-2 seconds at sharp steering”

Step 3: Quick Implementation

motor_pair.move_for_time(motor_pair.PAIR_1, 2500, 0, velocity=50)  # ~30 cm forward
await runloop.sleep_ms(300)
motor_pair.move_for_time(motor_pair.PAIR_1, 1500, 75, velocity=40)  # ~90° turn

Step 4: Physical Testing

• Deploy to robot, observe actual path
• Adjust durations based on observation: “Forward was close, turn was ~70°”

Step 5: Refinement or Conversion

• If approximate results sufficient, done!
• If precision needed, convert to position-based commands using measurement tools

Value: Get functional prototype in 10 minutes vs. 30+ minutes for calculated position-based approach. Perfect for exploring feasibility before committing to detailed implementation.

Physics Education Integration Workflow

For teaching kinematics concepts through hands-on experimentation:

Week 1: Distance = Velocity × Time Exploration

• Students program robots: various time/velocity combinations
• Measure actual distances traveled
• Create data tables: time (s), velocity (%), distance (cm)
• Calculate experimental “speed” from distance/time
• Compare across different velocity settings

Week 2: Graphical Analysis

• Plot distance vs. time for constant velocity → should be linear
• Plot distance vs. velocity for constant time → should be linear
• Calculate slopes, discuss physical meaning
• Introduce concept: slope of distance-time graph = speed

Week 3: Curve and Arc Investigation

• Measure curved paths (arc length) vs. straight-line displacement
• Explore how steering affects path geometry
• Introduction to concepts: trajectory, displacement vs. distance

Week 4: Battery Voltage Experiment

• Measure battery voltage before tests
• Repeat Week 1 experiments with various battery states
• Discover voltage affects actual speed even when velocity parameter constant
• Discuss implications for robotics: need feedback control for precision

Learning Outcomes: Students discover kinematic relationships through experimentation rather than memorizing formulas. The physical robot provides immediate, tangible feedback on abstract physics concepts.

Comparisons: Choosing the Right Control Method

When Time-Based Control Excels

Choreography and Demonstrations: When timing synchronization matters more than positional accuracy, time-based control offers simpler programming and natural alignment with musical beats or event sequences.

Teaching Kinematics: Time-based motion creates perfect laboratory for exploring velocity, distance, and time relationships. Students directly manipulate parameters appearing in physics equations, making abstract formulas concrete.

Rapid Prototyping: Early in project development, approximate navigation with quick time-based implementation lets teams test strategies before investing in precise calculations.

Multi-Robot Synchronization: Starting multiple robots simultaneously with identical time-based commands produces reasonably synchronized behaviors. Position-based commands might complete at different times due to variation in starting positions or mechanical differences.

Creative Expression: Student projects emphasizing artistry over technical precision (robot dances, storytelling demonstrations) benefit from time-based control’s intuitive nature.

When Position-Based Control Wins

Competition Robotics: Scoring zones, mission models, and game elements occupy fixed positions. Robots must reach precise locations regardless of battery state or surface conditions—position control essential.

Navigation Precision: Autonomous vehicles, warehouse robots, and manufacturing systems need reliable positioning. Time-based approximations insufficient for safety-critical or economically-critical applications.

Multi-Segment Paths: Complex paths with many turns accumulate error with time-based control. Position-based commands prevent error propagation.

Calibration and Repeatability: Scientific experiments, research applications, and systematic testing require reproducible results across trials—position control provides this consistency.

Student Assessment: When evaluating student understanding of calculation skills (circumference, angles, proportions), position-based programming demonstrates mathematical competency time-based approaches don’t assess.

Hybrid Approaches

Professional robotics typically combines paradigms. Example competition robot:

# Position-based for precision approach to scoring zone
motor_pair.move_for_degrees(motor_pair.PAIR_1, 1022, 0, velocity=50)  # Exactly 50 cm

# Position-based turn to face target
motor_pair.move_for_degrees(motor_pair.PAIR_1, 450, 80, velocity=40)  # Exactly 90° turn

# Time-based final approach (approximate OK, time-constrained)
motor_pair.move_for_time(motor_pair.PAIR_1, 800, 0, velocity=60)  # ~10 cm, done quickly

# Position-based return for next mission (precision matters again)
motor_pair.move_for_degrees(motor_pair.PAIR_1, -1472, 0, velocity=50)  # Back to start

Teaching students when to apply each paradigm develops engineering judgment—choosing appropriate tools for specific requirements.

Best Practices: Maximizing Time-Based Control Effectiveness

Calibration for Consistency

While time-based commands inherently vary more than position-based, systematic calibration improves consistency:

Establish Standard Operating Conditions:

• Define “minimum performance battery voltage” (recommend 7.8V for LEGO SPIKE)
• Select primary operating surface (carpet, tile, competition mat)
• Document ambient temperature if operating in varying conditions

Create Calibration Tables: For standard battery/surface combination, measure actual distances for reference durations:

Similar tables for turn angles with various steering values.

Apply Correction Factors: If actual distances consistently differ from theoretical, calculate correction:

Time_Corrected = Time_Desired × (Distance_Theoretical / Distance_Actual)

Battery Management Protocols

Pre-Performance Check:

import hub

battery_voltage = hub.battery.voltage()
if battery_voltage < 7800:  # 7.8V in millivolts
    # Warning: recharge recommended

Voltage-Adaptive Programming (Advanced):

battery_voltage = hub.battery.voltage()
velocity_adjusted = base_velocity × (battery_voltage / 8400)  # Normalize to full charge
motor_pair.move_for_time(motor_pair.PAIR_1, duration, steering, velocity=velocity_adjusted)

This advanced technique attempts to maintain consistent actual speed across battery voltages by adjusting velocity parameter proportionally.

Documentation Discipline

Time-based programs benefit enormously from comprehensive comments:

# CALIBRATION DATA: Tested on carpet, battery 8.2V, 2025-11-02
# At velocity=50: 1.0s ≈ 12cm, 2.0s ≈ 24cm, 3.0s ≈ 36cm

async def navigation_routine():
    # Segment 1: Approach scoring zone (~25 cm in 2.1s)
    motor_pair.move_for_time(motor_pair.PAIR_1, 2100, 0, velocity=50)
    
    # Segment 2: Turn to face exit (~80° in 1.4s at steering 75)
    motor_pair.move_for_time(motor_pair.PAIR_1, 1400, 75, velocity=40)

Documentation serves multiple purposes:

• Reminds future you of calibration context
• Helps teammates understand timing choices
• Facilitates troubleshooting when behavior changes

Case Study: Elementary School Robot Performance

Context: A third-grade class prepared a “Robot Storytelling” presentation for a school assembly. Students programmed robots to act out “The Three Little Pigs,” with three robots representing houses and one robot playing the wolf.

Why Time-Based Control: The performance needed synchronization with narration, which had fixed timing. Position precision mattered less than hitting narrative cues at the right moments.

Implementation Process:

Week 1 - Story Planning:

• Students broke 5-minute story into 12 key scenes
• Identified required robot actions for each scene
• Created timeline showing when each robot moves

Week 2 - Movement Vocabulary:

• Three student groups each developed basic movements for their robot:
  • “Brick house” (Robot 1): Slow, sturdy movements (velocity=30)
  • “Stick house” (Robot 2): Medium-speed movements (velocity=50)
  • “Straw house” (Robot 3): Quick, nervous movements (velocity=70)
  • “Wolf” (Robot 4): Aggressive, sharp turns

Week 3 - Scene Programming:

• Students programmed individual scenes using time-based commands
• Example Scene 5 (Wolf approaches Brick House):

  # Wolf moves menacingly toward brick house (3 seconds)
  wolf_pair.move_for_time(wolf_pair.PAIR_1, 3000, -15, velocity=40)
  
  # Brick house stands firm (doesn't move, shows strength)
  await runloop.sleep_ms(2000)

Week 4 - Rehearsal and Integration:

• Combined all scenes into full narrative
• Adjusted timing to match narrator’s reading pace
• Added “reset positions” code for repeated performances

Performance Results:

• Successfully performed for 200+ student/parent audience
• Robots hit narrative timing marks within 0.5 seconds across 6 performances
• Positional drift accumulated (robots ended 10-15 cm from ideal positions) but didn’t affect story
• Students received standing ovation

Educational Impact:

• Third-graders successfully programmed complex multi-robot sequence (normally considered advanced)
• Mathematical concepts reinforced: “If 2 seconds goes 20 centimeters, 3 seconds goes 30 centimeters”
• Collaborative skills: Four groups had to coordinate timing
• Creative confidence: Students saw robotics as storytelling medium, not just technical exercise

Teacher Reflection: “Time-based programming was absolutely the right choice. If we’d tried to calculate exact positions for every movement, we’d still be programming. Instead, students focused on creative storytelling and timing, using robotics as an expressive tool. The slight positional imprecision didn’t matter at all—audiences saw engaging performance, not technical demonstration.”

Advanced Considerations

Acceleration and Deceleration Profiles

LEGO motors don’t instantly reach target velocity; they accelerate gradually. For very short durations (<500ms), robots may never reach specified velocity, causing distance predictions to fail. If critical:

# Incorrect assumption: 500ms at velocity=80 travels 10cm
# Reality: Acceleration phase consumes 200ms, only 300ms at full speed → travels ~7cm

# Solution: Use longer durations or account for acceleration

Surface Transition Handling

Robots crossing from carpet to tile mid-movement experience friction change, affecting speed:

# Problem: 3-second movement, first 1.5s on carpet, last 1.5s on tile
# Carpet: ~10 cm/s effective speed → 15 cm
# Tile: ~13 cm/s effective speed → 19.5 cm
# Total: 34.5 cm (vs. 36 cm predicted for uniform surface)

# Solution: Separate movements at surface boundary

Multi-Robot Coordination Challenges

Identical time-based commands produce approximately synchronized motion, but mechanical variations cause drift:

# Three robots execute same code
# After 30 seconds, positions vary by ±5 cm typical, ±10 cm maximum
# For critical synchronization, implement periodic recalibration (e.g., start from fixed positions each scene)

External References

For deeper exploration of time-based control and robot choreography:

• LEGO Education SPIKE Prime Programming Reference: Complete API documentation including move_for_time specifications. Available at education.lego.com

• “Kinematic Education Through Robotics” - Journal of STEM Learning: Research demonstrating that hands-on robot manipulation of time/velocity/distance improves student understanding compared to traditional problem-solving worksheets.

Expanding Your Motion Control Knowledge

Explore complementary movement methods for complete LEGO SPIKE programming mastery:

• LEGO SPIKE Turn Planner: Master position-based turning with move_for_degrees for precision navigation

• LEGO Wheel Distance Explorer: Understand the fundamental geometry connecting rotations to distances

• LEGO Wheel Distance Explorer 3D: Understand the fundamental geometry connecting rotations to distances

• LEGO SPIKE move Turn Trainer: Learn continuous motion control for sensor-responsive behaviors

• Gray-wolf Robotics Tools Suite: Complete collection of LEGO SPIKE Prime planning and programming resources

Conclusion

Time-based motion control represents an often-overlooked but pedagogically powerful approach to robotics programming. While position-based control rightfully dominates precision navigation applications, time-based methods excel in choreography, teaching contexts, rapid prototyping, and creative expression scenarios.

The key to effective robotics education lies not in dogmatically favoring one paradigm over another, but in helping students understand the strengths, limitations, and appropriate contexts for each approach. Students who master both time-based and position-based control develop sophisticated engineering judgment—the ability to select appropriate tools based on project requirements rather than applying the same technique to every problem.

By integrating time-based programming alongside position-based methods, educators provide students with a complete robotics toolbox, preparing them for the diverse challenges they’ll encounter in advanced studies, competitions, and professional practice.

Master time-based motion control, and you’ve unlocked a powerful approach to creating expressive, synchronized, and intuitively programmed robot behaviors that bring joy to both programmers and audiences.