ros_sugar.robot.process#

ProcessSpec — external driver processes a plugin needs running.

Some plugins front hardware whose data arrives from a separate driver node: a LiDAR whose points come from a vendor SDK node, a depth camera with its own pipeline. Which driver that is, and how it must be configured, is exactly the robot-specific knowledge a plugin exists to absorb — a recipe author should not have to know it, and should not have to start it by hand.

A plugin declares such a process from robot.plugin.Plugin.required_processes; the Launcher owns it and brings it up through the same machinery as Launcher.add_ros_node. Plugins stay declarative and start nothing themselves, and the driver inherits launch’s supervision: respawn, captured output, and teardown ordered with the rest of the recipe. A plugin that spawned its own subprocess would get none of that, and would leak a process still holding the device if the launcher were killed.

Module Contents#

Classes#

ProcessSpec

One external ROS node a plugin needs running.

API#

class ros_sugar.robot.process.ProcessSpec#

Bases: ros_sugar.config.BaseAttrs

One external ROS node a plugin needs running.

The fields mirror the arguments of Launcher.add_ros_node, which is what the launcher passes this to.

Parameters:

  • package – ROS package holding the executable.

  • executable – Executable name.

  • name – Node name; defaults to the executable’s own.

  • parameters – Node parameters — dicts and/or paths to YAML files.

  • remappings – (from, to) topic/service remapping pairs.

  • arguments – Extra command-line arguments.

  • output – launch output configuration.

  • respawn – Restart the node if it exits. Defaults to True: a driver dying mid-run is the case this exists to survive.

  • respawn_delay – Seconds to wait before respawning.

  • precondition –

    Optional predicate, evaluated in the launcher process immediately before the node is added. Return False to skip it.

    Not a refinement — for a large class of drivers this is the difference between working and not. A driver that binds a fixed port (most LiDARs) cannot coexist with a second copy of itself, and many robots already run the vendor’s own instance from boot. Starting a second one gives a node that comes up cleanly and then never publishes, which reads as a crash and sends people looking in the wrong place. Detect the running instance here and return False.

property label: str#

Human-readable identifier for logs.

launch_kwargs() → Dict[str, Any]#

This spec as keyword arguments for Launcher.add_ros_node.

precondition is deliberately absent: it is the launcher’s business, not the launch system’s.

asdict(filter: Optional[Callable] = None) → Dict#
to_dict() → Dict#
asdict_explicit() → Dict#
from_dict(dict_obj: Dict) → None#
from_file(file_path: str, nested_root_name: Union[str, None] = None, get_common: bool = False) → bool#
to_json() → Union[str, bytes, bytearray]#
from_json(json_obj: Union[str, bytes, bytearray]) → None#
has_attribute(attr_name: str) → bool#
get_attribute_type(attr_name: str) → Optional[type]#
update_value(attr_name: str, attr_value: Any) → bool#
classmethod get_fields_info(class_object) → Dict[str, Dict[str, Any]]#