Capstone: Profiled Arm Tuning Report

Tune and document a profiled mechanism.

Season Robot CapstonesCapstone

In this lesson, you will:

Define states.
Tune profile constraints.
Validate repeatability.

Concept narrative

This project combines states, profiling, feedback, feedforward, Dashboard, and documentation into one mechanism students can explain.

Robot mental model

The arm is a controlled system, not a servo trick. It should move between named states with planned motion and known failure modes.

Implementation walkthrough

Implement enum states, profile generation, feedback follower, telemetry, and a tuning log. Validate small, medium, and full-range moves.

ProfiledArmReport.mdJava

State: SCORE
Target: 0.46
Max velocity:
Max acceleration:
kP:
Observed overshoot:
Next change:

Common mistakes and debugging

If tuning only works once, document why. Check battery, mechanical play, hard stops, and output saturation.

Practice

Submit a tuning report with constants, graphs, and failure-mode notes.

Checkpoint

The report names the mechanism, payload, units, soft limits, battery voltage, and software commit.
Targets for maximum error, overshoot, and settling are written before tuning begins.
Target, profile state, measured position, error, and output are graphed for every named arm state.
At least three cold-init repetitions per state meet the target or document a bounded exception.
The operator STOP path and safe state are demonstrated without exceeding mechanism limits.

Reflection check

Check your understanding before moving on.

Which record best supports a claim that a profiled arm tune is repeatable?

Target sequence, constraints, gains, battery/test conditions, trace, and observed overshoot.

Only the final kP value.

A video with no telemetry overlay.

A tune reaches the target but exceeds the arm’s safe travel near the hard stop. What is the correct disposition?

Accept it because the target was reached.

Reject the tune until safe limits and motion constraints are verified.

Increase maximum velocity to pass the hard stop sooner.

0 of 2 answered

References

Game Manual 0FTC community reference for programming, controls, and robot design.FTC DashboardLive telemetry, graphs, config variables, and camera streaming.

Capstone: Profiled Arm Tuning Report

Tune and document a profiled mechanism.

Season Robot CapstonesCapstone

In this lesson, you will:

Define states.
Tune profile constraints.
Validate repeatability.

Concept narrative

This project combines states, profiling, feedback, feedforward, Dashboard, and documentation into one mechanism students can explain.

Robot mental model

The arm is a controlled system, not a servo trick. It should move between named states with planned motion and known failure modes.

Implementation walkthrough

Implement enum states, profile generation, feedback follower, telemetry, and a tuning log. Validate small, medium, and full-range moves.

ProfiledArmReport.mdJava

State: SCORE
Target: 0.46
Max velocity:
Max acceleration:
kP:
Observed overshoot:
Next change:

Common mistakes and debugging

If tuning only works once, document why. Check battery, mechanical play, hard stops, and output saturation.

Practice

Submit a tuning report with constants, graphs, and failure-mode notes.

Checkpoint

The report names the mechanism, payload, units, soft limits, battery voltage, and software commit.
Targets for maximum error, overshoot, and settling are written before tuning begins.
Target, profile state, measured position, error, and output are graphed for every named arm state.
At least three cold-init repetitions per state meet the target or document a bounded exception.
The operator STOP path and safe state are demonstrated without exceeding mechanism limits.

Reflection check

Check your understanding before moving on.

Which record best supports a claim that a profiled arm tune is repeatable?

Target sequence, constraints, gains, battery/test conditions, trace, and observed overshoot.

Only the final kP value.

A video with no telemetry overlay.

A tune reaches the target but exceeds the arm’s safe travel near the hard stop. What is the correct disposition?

Accept it because the target was reached.

Reject the tune until safe limits and motion constraints are verified.

Increase maximum velocity to pass the hard stop sooner.

0 of 2 answered

References

Game Manual 0FTC community reference for programming, controls, and robot design.FTC DashboardLive telemetry, graphs, config variables, and camera streaming.