Feature: Drive joint-space robots through joint_jog
User Story
As someone with a robot that takes joint targets rather than a Cartesian velocity,
I want the same gamepad and the same console to drive it,
so that the lease, the deadman and the E-STOP are not rewritten per robot.
Requirements
Implement the port already specified in dora-node.yml: {names: [string], velocities: [float]}, joints named rather than positional so a
consumer cannot mistake the order.
A mode switch deciding whether the sticks mean Cartesian or joint motion, reachable from
both the pad and the console. The normalised six-vector is produced the same way either
way; only the scaling and the port differ.
The console needs joint controls and a way to show which mode it is in.
Publish joint_jogortwist, never both at once.
Acceptance Criteria
A joint-space consumer can be driven from the pad and from the console
Switching modes stops the robot first, rather than reinterpreting a held stick
is_active, the lease, the four deadman layers and the E-STOP latch behave
identically in both modes
The E-STOP stops a joint motion as it stops a Cartesian one
Notes
Do not start this without a consumer to test against. The port is written down in the
manifest and deliberately not implemented, because a port nothing wires reads as supported
while having never run.
The obvious first consumer is a lerobot SO-101, which is not near-term. Two things
about it shape the work, from resources/robotics/lerobot/software.md:
It takes joint positions in the normalised frame calibration defines, not velocities.
So something must integrate a joint_jog into a target position against joint limits.
That is stateful and robot-specific, and belongs in the robot node rather than here.
Its normal teleop is leader-follower — another SO-101 as the leader. A gamepad is a
different control mode, not the one the platform is built around.
Cartesian control of such an arm is a separate matter again: it needs inverse kinematics,
which is another node's job entirely. This node should not grow IK.
Contract: resources/robotics/teleop-contract.md in the vault.
# Feature: Drive joint-space robots through `joint_jog`
## User Story
As someone with a robot that takes joint targets rather than a Cartesian velocity,
I want the same gamepad and the same console to drive it,
so that the lease, the deadman and the E-STOP are not rewritten per robot.
## Requirements
- Implement the port already specified in `dora-node.yml`:
`{names: [string], velocities: [float]}`, joints named rather than positional so a
consumer cannot mistake the order.
- A mode switch deciding whether the sticks mean Cartesian or joint motion, reachable from
both the pad and the console. The normalised six-vector is produced the same way either
way; only the scaling and the port differ.
- The console needs joint controls and a way to show which mode it is in.
- Publish `joint_jog` **or** `twist`, never both at once.
## Acceptance Criteria
- [ ] A joint-space consumer can be driven from the pad and from the console
- [ ] Switching modes stops the robot first, rather than reinterpreting a held stick
- [ ] `is_active`, the lease, the four deadman layers and the E-STOP latch behave
identically in both modes
- [ ] The E-STOP stops a joint motion as it stops a Cartesian one
## Notes
**Do not start this without a consumer to test against.** The port is written down in the
manifest and deliberately not implemented, because a port nothing wires reads as supported
while having never run.
The obvious first consumer is a lerobot SO-101, which is **not near-term**. Two things
about it shape the work, from `resources/robotics/lerobot/software.md`:
- It takes joint **positions** in the normalised frame calibration defines, not velocities.
So something must integrate a `joint_jog` into a target position against joint limits.
That is stateful and robot-specific, and belongs in the robot node rather than here.
- Its normal teleop is leader-follower — another SO-101 as the leader. A gamepad is a
different control mode, not the one the platform is built around.
Cartesian control of such an arm is a separate matter again: it needs inverse kinematics,
which is another node's job entirely. This node should not grow IK.
Contract: `resources/robotics/teleop-contract.md` in the vault.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Feature: Drive joint-space robots through
joint_jogUser Story
As someone with a robot that takes joint targets rather than a Cartesian velocity,
I want the same gamepad and the same console to drive it,
so that the lease, the deadman and the E-STOP are not rewritten per robot.
Requirements
dora-node.yml:{names: [string], velocities: [float]}, joints named rather than positional so aconsumer cannot mistake the order.
both the pad and the console. The normalised six-vector is produced the same way either
way; only the scaling and the port differ.
joint_jogortwist, never both at once.Acceptance Criteria
is_active, the lease, the four deadman layers and the E-STOP latch behaveidentically in both modes
Notes
Do not start this without a consumer to test against. The port is written down in the
manifest and deliberately not implemented, because a port nothing wires reads as supported
while having never run.
The obvious first consumer is a lerobot SO-101, which is not near-term. Two things
about it shape the work, from
resources/robotics/lerobot/software.md:So something must integrate a
joint_joginto a target position against joint limits.That is stateful and robot-specific, and belongs in the robot node rather than here.
different control mode, not the one the platform is built around.
Cartesian control of such an arm is a separate matter again: it needs inverse kinematics,
which is another node's job entirely. This node should not grow IK.
Contract:
resources/robotics/teleop-contract.mdin the vault.