BB.Ufactory.Actuator.Joint (bb_ufactory v0.2.0)

Copy Markdown View Source

Joint-space position actuator for xArm joints.

One instance runs per joint. On receiving a %BB.Message.Actuator.Command.Position{} command, the actuator clamps the angle to joint limits and writes the target set_position into the controller's ETS table. The controller's 100 Hz loop reads all pending set_position values and batches them into a single cmd_move_joints frame.

All command transports (BB.Actuator.set_position/4 over pubsub, direct cast, synchronous call) converge on BB.Actuator.handle_command/2 — BB.Actuator.Server subscribes to the command topic, checks that the robot is armed, and gates payload types before the driver sees them.

Accepted commands

  • Command.Position — clamp to joint limits, write set_position to ETS.
  • Command.Stop — brake this joint by latching its current reported position as the target. The 100 Hz loop keeps commanding that position, so the firmware decelerates the joint and it stays put. If no report frame has arrived yet, the pending target is cleared instead — nothing has been dispatched, so clearing it cancels the motion.
  • Command.Hold — same latch as Stop; in position mode, holding the current angle actively resists external force. Refused when the current position is unknown (no report frame yet).

Per-joint "passive" stop does not exist on this hardware (motor enable is arm-wide), so both Stop and Hold brake at the current position. Making the whole arm safe is the controller's disarm/1.

Capabilities

Declares :position_feedback and :effort_feedback: the controller publishes BB.Message.Sensor.JointState (angles + torques from every ~100 Hz report frame) on [:sensor, controller_name], so joints driven by this actuator do not need a separate position sensor.

ETS Write

The actuator reads the current ETS row first to preserve current_position and current_torque written by the controller's report socket handler, then writes only the set_position field.

BeginMotion

A BB.Message.Actuator.BeginMotion message is published to [:actuator | bb.path] after each position command so that the open-loop position estimator can track expected arrival.