Skip to content
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
88 lines (68 sloc) 3.17 KB


Because different systems require different scheduling policies, the Robotics in Concert (ROCON) framework allows multiple scheduler implementations. The scheduler is a ROS node running on same master as the ROCON Conductor, services and other Solution components.

This concert_simple_scheduler ROS package implements a scheduler node in Python. It uses some infrastructure packages that other scheduler implementations can also use or modify.

ROS interface

simple_scheduler node

This node provides a relatively simple fixed-priority scheduler which allocates resources within each priority on a first-come, first-served basis.

Subscribed topics

rocon_scheduler (scheduler_msgs/SchedulerRequests)
Scheduler requests. Any ROCON service or application sending messages to the rocon_scheduler topic is called a requester.
concert_client_changes (concert_msgs/ConcertClients)
ROCON clients known to the Conductor.

Published topics

rocon_scheduler_0123456789abcdef0123456789abcdef (scheduler_msgs/SchedulerRequests)
Per-requester scheduler feedback. Each requester assigns itself a universally unique identifier and subscribes to a feedback topic using the hexadecimal string representation of its UUID.
resource_pool (scheduler_msgs/KnownResources)
The status of all ROCON clients currently managed by this scheduler.


~topic_name (string, default: rocon_scheduler)
Common name prefix to use for the request and feedback topics. Since the feedback topic is generated dynamically, it would otherwise be difficult to remap.


$ rosrun concert_simple_scheduler simple_scheduler


Each scheduler_msgs/SchedulerRequests message describes all resources currently desired by that requester. The status of each resource request is passed back and forth between the requester and the scheduler via scheduler_msgs/Request elements contained in the allocation and feedback topics.

Handling these messages and managing the resource request states can be tricky, because state changes flow over the two topics simultaneously. Both schedulers and requesters should use the concert_scheduler_requests package to perform the appropriate state transitions for each request.

You can’t perform that action at this time.