Access

Govern robot permissions using ROS 2 services that wrap the peaq RBAC pallets.

Role-based access control (RBAC) is exposed in ROS 2 through core_node. The services map one-to-one with the Robotics Python SDK but run under lifecycle management so you can gate access policies alongside mission logic.

The access services need the peaq-robotics-sdk package. The repository’s requirements.txt installs peaq-robot-sdk, a package without the access module, so after pip install -r requirements.txt run:

pip uninstall -y peaq-robot-sdk && pip install -U peaq-robotics-sdk

Capabilities

• Create roles that encapsulate operational capabilities (operator, maintenance)
• Define permissions (e.g., store_telemetry, emit_intent)
• Assign permissions to roles and grant roles to robot or user DIDs

Service Reference

Service	Type	Purpose
/peaq_core_node/access/create_role	peaq_ros2_interfaces/srv/AccessCreateRole	Add a new role identifier
/peaq_core_node/access/create_permission	peaq_ros2_interfaces/srv/AccessCreatePermission	Register a permission definition
/peaq_core_node/access/assign_permission	peaq_ros2_interfaces/srv/AccessAssignPermToRole	Attach a permission to a role
/peaq_core_node/access/grant_role	peaq_ros2_interfaces/srv/AccessGrantRole	Grant a role to a robot or user DID

All services take plain string fields and return a transaction hash, so you can follow progress on peaq/tx_status.

The SDK pads every role, permission and user value with 0 to 32 characters (or cuts it to the first 32), then UTF-8 encodes it as the 32-byte on-chain ID. Use ASCII IDs of 32 characters or fewer whose padded forms differ (robot and robot0 become the same ID). A full did:peaq: DID is longer than 32 characters, so pass a short user ID and keep the mapping to the DID in your fleet records. Roles and permissions are create-once per wallet: a second create_role or create_permission with the same ID fails on chain (EntityAlreadyExist) and the service returns an empty tx_hash.

Example Workflow

# 1. Create role
ros2 service call /peaq_core_node/access/create_role \
  peaq_ros2_interfaces/srv/AccessCreateRole \
  '{role: "operator", description: "Fleet operator"}'

# 2. Create permission
ros2 service call /peaq_core_node/access/create_permission \
  peaq_ros2_interfaces/srv/AccessCreatePermission \
  '{permission: "telemetry:write", description: "Write telemetry"}'

# 3. Assign permission to role
ros2 service call /peaq_core_node/access/assign_permission \
  peaq_ros2_interfaces/srv/AccessAssignPermToRole \
  '{permission: "telemetry:write", role: "operator"}'

# 4. Grant role to robot DID
ros2 service call /peaq_core_node/access/grant_role \
  peaq_ros2_interfaces/srv/AccessGrantRole \
  '{role: "operator", user: "did:peaq:5G..."}'

Combine the responses with ros2 topic echo /peaq/tx_status to watch each submission.

Automation Pattern

• Trigger RBAC provisioning from CI whenever a new robot identity is created.
• Use a ROS 2 Node (Python/C++) that batches service calls and verifies outcomes before declaring a robot operational.
• Persist granted roles using your fleet management system for quick audits.

Best Practices

• Prefix permissions with domain context (telemetry:write, mission:cancel) to avoid collisions.
• Use different roles for humans and robots even if they share capabilities. This keeps grants revocable per actor type.
• Log RBAC service responses for compliance; each one carries the transaction hash.

Next, wire RBAC with secure data flows by configuring Verifiable Storage.