cristhian
fb14545850
`dora topic echo` and `dora topic hz` only read the wire when the dataflow asks for it. Turning it on here means the velocities this node sends can be watched live, and their cadence measured, without the bench printing anything and without a robot — which is most of what testing this node with only a gamepad needs. Measured with it: the get_state poll runs at 1.88 Hz against a configured STATE_POLL_S of 0.5.
52 lines
1.5 KiB
YAML
52 lines
1.5 KiB
YAML
# The repo's own example, and what CI validates.
|
|
#
|
|
# Self-contained on purpose: teleop plus a bench stand-in for the arm and the
|
|
# browser, both built from this checkout, so `dora validate` resolves every
|
|
# manifest from `path:` and CI needs no gamepad, no robot and no sibling clones.
|
|
#
|
|
# This is **not** the real stack. The bench answers services and publishes
|
|
# telemetry but never moves anything — it exists so the node can be driven from
|
|
# a real gamepad with no arm in the room. README.md carries the three-node
|
|
# wiring a consumer actually uses.
|
|
|
|
strict_types: true
|
|
|
|
# Lets `dora topic echo` and `dora topic hz` read what is on the wire, so the
|
|
# velocities this node sends can be watched without the bench printing them —
|
|
# and without a robot. Costs nothing when nobody is looking.
|
|
debug:
|
|
enable_debug_inspection: true
|
|
|
|
nodes:
|
|
- id: teleop
|
|
path: dora-teleop
|
|
build: pip install .
|
|
inputs:
|
|
tick: dora/timer/millis/50
|
|
clients: bench/clients
|
|
response: bench/response
|
|
robot_state: bench/robot_state
|
|
tcp_pose: bench/tcp_pose
|
|
joint_pose: bench/joint_pose
|
|
outputs:
|
|
- jog
|
|
- request
|
|
- ui_state
|
|
env:
|
|
SPEED_MM_S: "60"
|
|
SPEED_DEG_S: "30"
|
|
|
|
- id: bench
|
|
path: examples/bench.py
|
|
inputs:
|
|
tick: dora/timer/millis/200
|
|
jog: teleop/jog
|
|
request: teleop/request
|
|
ui_state: teleop/ui_state
|
|
outputs:
|
|
- response
|
|
- robot_state
|
|
- tcp_pose
|
|
- joint_pose
|
|
- clients
|