fix the gamepad layout and refuse a pad the node cannot read

Conversation 0 Commits 3 Files Changed 14

+808 -446

3 Commits

Author	SHA1	Message	Date
cristhian	e3fc538e5d	docs: simplify the README and record the pad layout validate / validate (pull_request) Successful in 58m44s Details validate / test (pull_request) Successful in 58m45s Details validate / markdownlint (pull_request) Successful in 58m40s Details The README carried a lot of rationale that AGENTS.md already holds; what is left is the tables a consumer wires against. It gains the swept axis and button indices, and says plainly that the axes check themselves at runtime and the buttons cannot.	2026-09-16 18:06:12 -03:00
cristhian	eede2e5774	update dataflow-gamepad to drive the arm instead of the bench It now runs joy, teleop and dora-ulite6 with the probe declared and the console shut, so a pad can be checked against the arm that will actually move. ROBOT_IP in both arm dataflows points at the bench arm. The run recipe drops dora up + dora start: dora 1.0.1 refuses to start a dataflow holding git: nodes from a coordinator, reporting that no build was run straight after one that succeeded. That costs the file dora topic, which needs a coordinator to read the wire.	2026-09-16 18:06:12 -03:00
cristhian	7a0847893c	fix gamepad layout and refuse a pad whose axes disagree An Xbox One S pad over Bluetooth numbers its controls differently from the indices this node shipped with: the right stick is on axes 2 and 3, the triggers on 4 and 5, and the buttons carry gaps at 2 and 5. Against the old layout an untouched pad reported a resting trigger as full right-stick deflection, which asked for 30 deg/s of pitch while lying on the desk, held the lease for ever so GAMEPAD_IDLE_RELEASE_S never fired, and moved a real arm into a controller error. X toggled freedrive and LB was the E-STOP, so the resulting latch could not be released from the pad at all. Layout now carries the swept indices. Each pad is also measured the first time it is seen at rest: a stick must rest near centre and a trigger near the bottom of its travel, and a pad that does not fit reads as absent and is named in the log rather than driving an arm from a numbering nobody checked. The measured rest becomes each axis's zero, so a worn stick's tilt is subtracted rather than deadzoned away and a trigger that reads 0 until it first moves stops reading as half pressed. Rest is never re-measured while the pad is in use, because doing that under a held stick would record the deflection as centre and the arm would move when the operator let go. The probe drives from the same calibration, so what it prints is still what the arm would get, and it shows the mismatch. Tests name their controls through axes_for and buttons_for instead of numbering them; the positional lists are why a wrong index passed a green suite.	2026-09-16 18:06:06 -03:00

Author

SHA1

Message

Date

cristhian

e3fc538e5d

docs: simplify the README and record the pad layout

validate / validate (pull_request) Successful in 58m44s

Details

validate / test (pull_request) Successful in 58m45s

Details

validate / markdownlint (pull_request) Successful in 58m40s

Details

The README carried a lot of rationale that AGENTS.md already holds; what is
left is the tables a consumer wires against. It gains the swept axis and
button indices, and says plainly that the axes check themselves at runtime
and the buttons cannot.

2026-09-16 18:06:12 -03:00

cristhian

eede2e5774

update dataflow-gamepad to drive the arm instead of the bench

It now runs joy, teleop and dora-ulite6 with the probe declared and the
console shut, so a pad can be checked against the arm that will actually
move. ROBOT_IP in both arm dataflows points at the bench arm.

The run recipe drops dora up + dora start: dora 1.0.1 refuses to start a
dataflow holding git: nodes from a coordinator, reporting that no build was
run straight after one that succeeded. That costs the file dora topic, which
needs a coordinator to read the wire.

2026-09-16 18:06:12 -03:00

cristhian

7a0847893c

fix gamepad layout and refuse a pad whose axes disagree

An Xbox One S pad over Bluetooth numbers its controls differently from the
indices this node shipped with: the right stick is on axes 2 and 3, the
triggers on 4 and 5, and the buttons carry gaps at 2 and 5. Against the old
layout an untouched pad reported a resting trigger as full right-stick
deflection, which asked for 30 deg/s of pitch while lying on the desk, held
the lease for ever so GAMEPAD_IDLE_RELEASE_S never fired, and moved a real
arm into a controller error. X toggled freedrive and LB was the E-STOP, so
the resulting latch could not be released from the pad at all.

Layout now carries the swept indices. Each pad is also measured the first
time it is seen at rest: a stick must rest near centre and a trigger near
the bottom of its travel, and a pad that does not fit reads as absent and is
named in the log rather than driving an arm from a numbering nobody checked.
The measured rest becomes each axis's zero, so a worn stick's tilt is
subtracted rather than deadzoned away and a trigger that reads 0 until it
first moves stops reading as half pressed.

Rest is never re-measured while the pad is in use, because doing that under
a held stick would record the deflection as centre and the arm would move
when the operator let go. The probe drives from the same calibration, so
what it prints is still what the arm would get, and it shows the mismatch.

Tests name their controls through axes_for and buttons_for instead of
numbering them; the positional lists are why a wrong index passed a green
suite.

2026-09-16 18:06:06 -03:00

fix the gamepad layout and refuse a pad the node cannot read #5