A verified simulated controller.

Combine geometry, estimation, control and independent operating checks. This workbench uses three explicitly separate public scenarios: noisy cart control, a planned planar arm and guarded cart motion. Arm tracking tests noisy feedback against the reference and saves its configuration for replay. Neither model validates a physical robot. Human artifact review and learner pilots remain pending.

Report: draft. Storage: loading. Version 4 backups include these configurations and reports. Local progress does not sync between devices; export before clearing browser data. Editing evidence reopens the draft and does not alter lesson achievements.

Project requirements version 2: reference plus executed raw/filter arm comparisons. Earlier submissions keep their original scope; report submission is not mastery.

1. Collect and inspect evidence

Keep a matched raw/Kalman control pair, one independently accepted arm trajectory, and the same blocking-wall scenario with its motion guard on/off. Also save raw and predicted-filter arm runs with matched reference, noise, bias and gain; both must execute. Failed execution outcomes remain useful evidence and are not required to pass. Eight saved configurations maximum. Repeated runs use public development scenarios, not reserved evaluation.

2. Review saved configurations

0/8 saved. Imported scores and traces are ignored; the bounded inputs are replayed below and in the downloadable report.

3. Explain the evidence

Name capture IDs, task endpoints, success requirements and operating boundaries. Separate cart, arm and wall scenarios.

Explain world/relative joint angles, whole-link collisions, cubic timing and the difference between sampled planning and verified clearance.

Compare matched raw/filter configurations, current-state RMSE, force variation and task outcomes. Distinguish matched noise offsets from identical trajectories.

Compare the same wall scenario with its guard on/off. Explain brake assumptions, violations, latching and why stopping is not task completion.

State which modeled scenarios you accept, reject or leave unresolved, and what would trigger stop, re-evaluation or further observation.

Declare public practice exposure, noise/model assumptions, omitted dynamics and what independent tests and physical evidence would still be needed.

Code is inert. Implementation proficiency needs runnable geometry, estimator and verification code, tests, richer simulator work and independent review. A presence check cannot establish it.

4. Submit and assess separately

Report submission checks text presence and matched configurations, not the quality of reasoning or code. Passing the separate transfer cases below also does not replace human review. Existing published path requirements are unchanged.

• Capture raw and Kalman control with matched noise, bias and assumed variance.
• Capture a trajectory that passes the declared independent checks.
• Capture the same blocking-wall scenario with the motion guard on and off.
• Capture raw and predicted-filter arm tracking with matched reference, noise, bias and gain; both must execute.
• Write the task report field.
• Write the geometry report field.
• Write the estimation report field.
• Write the runtime report field.
• Write the decision report field.
• Write the limits report field.