Back to Prompt Library
implementation
Build the application
Inspect the original prompt language first, then copy or adapt it once you know how it fits your workflow.
Linked challenge: Build a Robot-Cell Payload Inertia Validation Engine
Format
Code-aware
Lines
63
Sections
11
Linked challenge
Build a Robot-Cell Payload Inertia Validation Engine
Prompt source
Original prompt text with formatting preserved for inspection.
63 lines
11 sections
No variables
1 code block
## Build
Inspect dynamic payload weight and inertia matrix estimates against MoveIt robot kinematic limits. Flag parameter drift and synthesize joint torque limit adjustments to ensure mechanical safety before initiating high-speed production runs.
## User
Robotics Calibration Engineer
## Workflow
1. Ingest estimated 6-DOF payload inertia matrices, payload mass, and center of mass offsets.
2. Calculate expected joint torques during maximum acceleration using MoveIt dynamic models.
3. Determine whether required joint torques exceed actuator limits based on payload configurations.
4. Synthesize validated payload parameters and generate a dynamic safety sign-off sheet for controllers.
## Interface
Dynamic payload viewer displaying center of mass offsets, joint torque utilization charts, and sign-off forms.
## Data
Simulated dynamic payload parameter JSON records (simplified synthetic app records, not complete official schema files).
Starter examples below are synthetic. They are not downloaded records.
## Source
[MoveIt robotics](https://raw.githubusercontent.com/moveit/moveit2/main/README.md)
MoveIt dynamics and kinematic limits from moveit_core to evaluate joint limits.
## Tools
ray-serve, pydantic, numpy.
Serves high-throughput joint torque calculations across multi-robot production lines via scalable endpoints.
Local model for fast mathematical validation or hosted LLM for generating dynamic sign-off certificates.
## Deliverables
Submit runnable source, pinned dependencies, setup commands, a working interface, example outputs, and a recorded end-to-end demo. Include tests and an action log.
## Acceptance
- Computes expected maximum joint torque exactly as (payload_mass_kg * peak_acceleration_rad_s2 * com_offset_x_m).
- Rejects payload configurations where computed max torque strictly exceeds max_torque_limit_nm.
- Outputs validated payload status and required torque constraints for the safety review team.
## Starter Examples
```json
[
{
"input": {
"robot_id": "ROBOT-PALLET-01",
"payload_mass_kg": 25,
"com_offset_x_m": 0.1,
"peak_acceleration_rad_s2": 15,
"max_torque_limit_nm": 50
},
"expected_output": {
"max_torque_required_nm": 37.5,
"within_limits": true,
"status": "DYNAMICS_ACCEPTED"
}
},
{
"input": {
"robot_id": "ROBOT-PALLET-01",
"payload_mass_kg": 45,
"com_offset_x_m": 0.3,
"peak_acceleration_rad_s2": 15,
"max_torque_limit_nm": 150
},
"expected_output": {
"max_torque_required_nm": 202.5,
"within_limits": false,
"status": "EXCEEDS_TORQUE_LIMITS"
}
}
]
```
## Safety
Read-only dynamics evaluation; torque configurations are reviewed and manually confirmed before writing to hardware.
Use mock external writes. Require human review before any real deployment.Adaptation plan
Keep the source stable, then change the prompt in a predictable order so the next run is easier to evaluate.
Keep stable
Hold the task contract and output shape stable so generated implementations remain comparable.
Tune next
Update libraries, interfaces, and environment assumptions to match the stack you actually run.
Verify after
Test failure handling, edge cases, and any code paths that depend on hidden context or secrets.