-
 
No version for distro humble. Known supported distros are highlighted in the buttons above.

Package Summary

Tags No category tags.
Version 2.2.6
License Apache License 2.0
Build type AMENT_PYTHON
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/open-rmf/rmf_ros2.git
VCS Type git
VCS Version iron
Last Updated 2024-11-12
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

Node for a fixed 24-hour rotating charger usage schedule

Additional Links

No additional links.

Maintainers

  • Grey

Authors

No additional authors.

A simple node that takes in a yaml file that describes a schedule for charger usage in an RMF scenario. The node will watch the clock and publish the appropriate commands to change the chargers of the robots.

The format for the schedule looks like this:

"my_fleet_name":
    "00:00": { "robot_1": "charger_A", "robot_2": "charger_B", "robot_3": "queue_A" }
    "01:55": { "robot_1": "queue_B" }
    "02:00": { "robot_3": "charger_A", "robot_1": "queue_A" }
    "03:55": { "robot_2": "queue_B" }
    "04:00": { "robot_1": "charger_B", "robot_2": "queue_A" }

The time format is "HH:MM" where HH ranges from 00 to 23 and MM ranges from 00 to 59. Note that quotes are important because otherwise the yaml format may confuse the meaning of the colon :.

The schedule will cycle every 24 hours.

For each timestamp, only robots that are explicitly mentioned will have their dedicated charger changed. It is the responsibility of the schedule file author to make sure that two robots are never assigned the same charger at the same time. Failing to ensure this may cause traffic and task management to misbehave.

When run in simulation mode (--ros-args --use-sim-time), the time 00:00 in the schedule will correspond to t=0.0 in simulation time.

When run without sim time on, the hours and minutes will correspond to the local timezone of the machine that the node is run on. To choose a specific timezone instead of using the system’s local timzeone, use the --timezone argument and provide the desired TZ identifier string.

It is advisable that you always put a 00:00 entry that indicates all of the intended charger assignments at midnight. When the node is launched, it will move through the schedule from the earliest entry up until the last relevant one and issue an initial charger assignment message based on what the assignments would have been if the schedule had run from 00:00.

CHANGELOG

Changelog for package rmf_charging_schedule

2.2.6 (2024-07-12)

2.2.5 (2023-12-22)

2.2.4 (2023-12-15)

  • First release

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged rmf_charging_schedule at Robotics Stack Exchange

Package Summary

Tags No category tags.
Version 2.7.2
License Apache License 2.0
Build type AMENT_PYTHON
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/open-rmf/rmf_ros2.git
VCS Type git
VCS Version jazzy
Last Updated 2024-06-17
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

Node for a fixed 24-hour rotating charger usage schedule

Additional Links

No additional links.

Maintainers

  • Grey

Authors

No additional authors.

A simple node that takes in a yaml file that describes a schedule for charger usage in an RMF scenario. The node will watch the clock and publish the appropriate commands to change the chargers of the robots.

The format for the schedule looks like this:

"my_fleet_name":
    "00:00": { "robot_1": "charger_A", "robot_2": "charger_B", "robot_3": "queue_A" }
    "01:55": { "robot_1": "queue_B" }
    "02:00": { "robot_3": "charger_A", "robot_1": "queue_A" }
    "03:55": { "robot_2": "queue_B" }
    "04:00": { "robot_1": "charger_B", "robot_2": "queue_A" }
parking: ["queue_A", "queue_B"]

The time format is "HH:MM" where HH ranges from 00 to 23 and MM ranges from 00 to 59. Note that quotes are important because otherwise the yaml format may confuse the meaning of the colon :.

The schedule will cycle every 24 hours.

For each timestamp, only robots that are explicitly mentioned will have their dedicated charger changed. It is the responsibility of the schedule file author to make sure that two robots are never assigned the same charger at the same time. Failing to ensure this may cause traffic and task management to misbehave.

When run in simulation mode (--ros-args --use-sim-time), the time 00:00 in the schedule will correspond to t=0.0 in simulation time.

When run without sim time on, the hours and minutes will correspond to the local timezone of the machine that the node is run on. To choose a specific timezone instead of using the system’s local timzeone, use the --timezone argument and provide the desired TZ identifier string.

It is advisable that you always put a 00:00 entry that indicates all of the intended charger assignments at midnight. When the node is launched, it will move through the schedule from the earliest entry up until the last relevant one and issue an initial charger assignment message based on what the assignments would have been if the schedule had run from 00:00.

If any of the waypoints are parking points instead of charging points, put them into a list called parking. Note that this node does not support the existence of a fleet with the name parking.

CHANGELOG

Changelog for package rmf_charging_schedule

2.7.2 (2024-06-18)

2.7.1 (2024-06-11)

  • Fix charging status (#347)
  • Contributors: Grey

2.7.0 (2024-06-01)

2.6.0 (2024-03-13)

2.5.0 (2023-12-22)

2.4.0 (2023-12-15)

  • First release

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

System Dependencies

No direct system dependencies.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged rmf_charging_schedule at Robotics Stack Exchange

Package Summary

Tags No category tags.
Version 2.8.0
License Apache License 2.0
Build type AMENT_PYTHON
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/open-rmf/rmf_ros2.git
VCS Type git
VCS Version main
Last Updated 2024-11-12
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

Node for a fixed 24-hour rotating charger usage schedule

Additional Links

No additional links.

Maintainers

  • Grey

Authors

No additional authors.

A simple node that takes in a yaml file that describes a schedule for charger usage in an RMF scenario. The node will watch the clock and publish the appropriate commands to change the chargers of the robots.

The format for the schedule looks like this:

"my_fleet_name":
    "00:00": { "robot_1": "charger_A", "robot_2": "charger_B", "robot_3": "queue_A" }
    "01:55": { "robot_1": "queue_B" }
    "02:00": { "robot_3": "charger_A", "robot_1": "queue_A" }
    "03:55": { "robot_2": "queue_B" }
    "04:00": { "robot_1": "charger_B", "robot_2": "queue_A" }
parking: ["queue_A", "queue_B"]

The time format is "HH:MM" where HH ranges from 00 to 23 and MM ranges from 00 to 59. Note that quotes are important because otherwise the yaml format may confuse the meaning of the colon :.

The schedule will cycle every 24 hours.

For each timestamp, only robots that are explicitly mentioned will have their dedicated charger changed. It is the responsibility of the schedule file author to make sure that two robots are never assigned the same charger at the same time. Failing to ensure this may cause traffic and task management to misbehave.

When run in simulation mode (--ros-args --use-sim-time), the time 00:00 in the schedule will correspond to t=0.0 in simulation time.

When run without sim time on, the hours and minutes will correspond to the local timezone of the machine that the node is run on. To choose a specific timezone instead of using the system’s local timzeone, use the --timezone argument and provide the desired TZ identifier string.

It is advisable that you always put a 00:00 entry that indicates all of the intended charger assignments at midnight. When the node is launched, it will move through the schedule from the earliest entry up until the last relevant one and issue an initial charger assignment message based on what the assignments would have been if the schedule had run from 00:00.

If any of the waypoints are parking points instead of charging points, put them into a list called parking. Note that this node does not support the existence of a fleet with the name parking.

CHANGELOG

Changelog for package rmf_charging_schedule

2.8.0 (2024-06-12)

2.7.1 (2024-06-11)

  • Fix charging status (#347)
  • Contributors: Grey

2.7.0 (2024-06-01)

2.6.0 (2024-03-13)

2.5.0 (2023-12-22)

2.4.0 (2023-12-15)

  • First release

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Package Dependencies

System Dependencies

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged rmf_charging_schedule at Robotics Stack Exchange

No version for distro noetic. Known supported distros are highlighted in the buttons above.
No version for distro ardent. Known supported distros are highlighted in the buttons above.
No version for distro bouncy. Known supported distros are highlighted in the buttons above.
No version for distro crystal. Known supported distros are highlighted in the buttons above.
No version for distro eloquent. Known supported distros are highlighted in the buttons above.
No version for distro dashing. Known supported distros are highlighted in the buttons above.
No version for distro galactic. Known supported distros are highlighted in the buttons above.
No version for distro foxy. Known supported distros are highlighted in the buttons above.
No version for distro lunar. Known supported distros are highlighted in the buttons above.
No version for distro jade. Known supported distros are highlighted in the buttons above.
No version for distro indigo. Known supported distros are highlighted in the buttons above.
No version for distro hydro. Known supported distros are highlighted in the buttons above.
No version for distro kinetic. Known supported distros are highlighted in the buttons above.
No version for distro melodic. Known supported distros are highlighted in the buttons above.