Teleop improvements

[caguero]

What this adds

This patch adds four changes to the gamepad teleop tool:

1. The mapping tool owns its joy_node. Mapping is now one command. If nothing is publishing /joy, the tool starts its own joy_node (with the autorepeat the baseline capture needs) and stops it on exit, spawned with the parent death signal so the helper dies even if the tool is killed. A running teleop session's joy_node is detected and reused. The old flow required a background joy_node, and forgetting to kill it left a stale publisher that would break the next teleop session.

2. joy_calibrate is now joy_map (c1197f3). The tool discovers which physical control drives which function. The executable, node, docs and config headers are renamed.

3. One shared pad mapping (d8d8f13). The mapping describes the pad, not a vehicle, so the three per vehicle copies collapse into one config/pad/.

4. Store mapping config in a user dir (feb5299). joy_map writes $ROS_HOME/bluerobotics_teleop/pad/ and the launch prefers it over the shipped defaults, logging which it loaded. Writing into the installed share only worked under a symlink install: a copy install would lost the mapping on rebuild and a binary install cannot write /opt/ros at all. Same pattern as configure_vehicle.py --cache.

How to test

ros2 run bluerobotics_teleop joy_map

1. With nothing else running: a joy_node appears for the walkthrough and is gone after quitting.
2. The walkthrough saves under ~/.ros/bluerobotics_teleop/pad/; ros2 launch bluerobotics_teleop teleop.launch.py vehicle:=bluerov2 (or blueboat, bluerov2_heavy) logs Pad mapping: <path> and every vehicle drives from that one mapping. Delete the directory to fall back to the shipped defaults.
3. colcon test --packages-select bluerobotics_teleop.

[bsb808]

Reviewing this got me looking at the tool it wraps rather than the change itself, and two design questions came out of it. Neither is a reason to hold up the PR, but both get more expensive to act on the longer the tool sits where it is.

Where it lives. Nothing about this walkthrough is specific to the BlueROV2 or the BlueBoat, or to marine vehicles at all. It asks which stick and which button, and writes out the input side config the teleop stack reads. That is useful for any teleop task in the project, and arguably well beyond it. Two options worth weighing: move it to gz-maritime so it is available project wide rather than to the two Blue Robotics vehicles, and if it proves itself there, consider whether it wants to be upstreamed — this feels like a gap in the ROS teleop tooling generally, not something we should be the only ones with.

Does moving it to gz-maritime fit how you were thinking about the teleop package's scope, or is there a reason to keep it with the vehicles?

[bsb808]

What it is called. I do not think "calibrate" is the right word. Calibration on a gamepad conventionally means setting the stick zero, the travel limits, and the deadzone, and that is the driver's job — jscal at the OS level, joy_node's deadzone parameter at the ROS level. What this tool does is discover which physical control maps to which function, which is closer to auto configuration, or a binding or mapping step. The distinction matters because the name is what a user reads before deciding whether the tool solves their problem: someone with a drifting stick would reasonably reach for something called joy_calibrate and come away unhelped. Something like joy_map or joy_configure would set the right expectation. The rename touches the executable name, the node name, the docs section and the config file headers, so it is cheapest now while the package is pre release and nothing downstream depends on the name.

[caguero]

What it is called. I do not think "calibrate" is the right word. Calibration on a gamepad conventionally means setting the stick zero, the travel limits, and the deadzone, and that is the driver's job — jscal at the OS level, joy_node's deadzone parameter at the ROS level. What this tool does is discover which physical control maps to which function, which is closer to auto configuration, or a binding or mapping step. The distinction matters because the name is what a user reads before deciding whether the tool solves their problem: someone with a drifting stick would reasonably reach for something called joy_calibrate and come away unhelped. Something like joy_map or joy_configure would set the right expectation. The rename touches the executable name, the node name, the docs section and the config file headers, so it is cheapest now while the package is pre release and nothing downstream depends on the name.

Thanks for the suggestion. I renamed it to joy_map as suggested. I hope it's more clear. c1197f3

[caguero]

What it is called. I do not think "calibrate" is the right word. Calibration on a gamepad conventionally means setting the stick zero, the travel limits, and the deadzone, and that is the driver's job — jscal at the OS level, joy_node's deadzone parameter at the ROS level. What this tool does is discover which physical control maps to which function, which is closer to auto configuration, or a binding or mapping step. The distinction matters because the name is what a user reads before deciding whether the tool solves their problem: someone with a drifting stick would reasonably reach for something called joy_calibrate and come away unhelped. Something like joy_map or joy_configure would set the right expectation. The rename touches the executable name, the node name, the docs section and the config file headers, so it is cheapest now while the package is pre release and nothing downstream depends on the name.

I'm not sure about this one: Mostly for two reasons: (1) this is a pure ROS package not even related with simulation. (2) it has a built-in mixer for these two vehicles. You don't teleoperate the thruster directly, you use the keypad to specify where do you want to go, and the mixer, translates that into thruster commands. I think the optimal solution should be to make a contribution to the upstream teleop_twist_joy package, and leave here the very minimum code.

[bsb808]

@caguero I'm a little confused with the two different replies to the What it is called suggestion - one seems positive and the other has a question. In the second one, when you say "I'm not sure about this one:" - is there a specific aspect you of the comment you are unsure about?

The mixer and the calibration/configuration I see as two separate issues. The mixer (close to) vehicle specific. There are some general frames, but the mixer config would be best alongside each vehicle.

The configuration of the input device - which joy to use - seems like it does not belong alongside a specific vehicle or set of vehicles.

I may be misunderstanding what you are trying to accomplish. I think that is the hazard of trying to infer intent from the implementation - if I don't understand what you are trying to accomplish it makes it hard to provide constructive comments on the implementation.

[caguero]

I may be misunderstanding what you are trying to accomplish. I think that is the hazard of trying to infer intent from the implementation - if I don't understand what you are trying to accomplish it makes it hard to provide constructive comments on the implementation.

Don't be mad at me :)

I updated this PR and the description to capture all improvements in the teleop tool. Hopefully the description shows better the intent now. And I agree that there is some general-purpose functionality here, that ideally we should upstream, more than moving it to gz-maritime in my opinion.

[bsb808]

This is very cool set of features for configuring the joystick.

See associated PRs in slack

[caguero]

This is very cool set of features for configuring the joystick.

See associated PRs in slack

Thanks for the suggestions, merged most of them!