Coordinate conversion and motion API boundaries

This page consolidates the public interface in source_reference/dobot_core/dobot_ctrl.py and the existing implementation audit. It does not claim hardware validation.

Delegation

DobotCtrl.p2j(p_type_pos), j2p(j_type_pos), and dev(base, offset) delegate to the corresponding DobotTcp methods. DobotCtrl.move() forwards target, motion_mode, coord_type, path_blend, offset, pose, speed, accel, decel, and is_async to the backend. A public parameter is not proof that its behavior is implemented.

MG400 coordinate constraints

The shared Cartesian representation is [x, y, z, rx, ry, rz]; MG400 uses [x, y, z, r], with r = rz. Independent rx and ry rotations cannot be realized. The shared joint representation is [j1, j2, j3, j4, j5, j6], while MG400 only drives J1–J4. Unsupported components must not be assumed to be silently valid.

Motion support

Previous source audits map Cartesian PTP to MovJ, Cartesian LINE to MovL, and joint PTP to JointMovJ. Semantics-preserving CIRCLE/SPLINE support, trajectory generation for rotate(), and some options such as path_blend remain unimplemented or unverified. is_async=False uses Sync(), but that alone does not establish healthy communication or an alarm-free completion.

Verification scope

This is static source analysis, not a hardware test. Coordinate frames, joint limits, and fault behavior require controlled verification with the robot and its safety procedures.