|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
Messages
Services
Plugins
Recent questions tagged power_switching_tools_ros at Robotics Stack Exchange
|
power_switching_tools_ros package from jsk_3rdparty repovoicevox chaplus_ros emotion_analyzer gdrive_ros google_chat_ros influxdb_store power_switching_tools_ros respeaker_ros ros_speech_recognition rospatlite sesame_ros switchbot_ros |
ROS Distro
|
Package Summary
| Version | 3.0.0 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/jsk-ros-pkg/jsk_3rdparty.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2026-11-05 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Shun Hasegawa
- Kei Okada
Authors
- Shun Hasegawa
power_switching_tools_ros
ROS tools for power switching tools.
Supported tools are:
USB-Serial troubleshooter
Preparation
Udev setting
This is optional, but we recommend this setting because USB-Serial troubleshooter is sometimes suddenly disconnected and its device file changes.
rosrun power_switching_tools_ros setup_udev_for_usb_serial_troubleshooter <serial_number> <symlink_name>
# <serial_number> : The serial number of your USB-Serial troubleshooter (e.g., 001A02F2046C). You can check the serial number by "udevadm info --name=/dev/ttyACM* --attribute-walk"
# <symlink_name> : The name to create as a symbolic link in /dev (e.g., usb_serial_troubleshooter1)
Connecting USB-Serial troubleshooter
When inserting your USB-Serial troubleshooter to your PC, check if LED in the troubleshooter becomes blue after a few moments. If it remains red, the connection between the troubleshooter and the PC fails to be established. If you face this phenomenon, try the following:
- Reversing USB-C connector of USB hub/adapter/cable if you connect the troubleshooter to a USB hub/adapter/cable connected to a USB-C port of the PC
- Connecting the troubleshooter to a USB-A port of the PC directly (not via a USB hub)
- Connecting the troubleshooter to a USB-C port of the PC via an adapter/cable (example)
- Changing USB hub/adapter/cable
- Changing the insertion process. Our experience has shown that success is more likely to be achieved if the insertion is stopped at a shallow point and then immediately deepened
- Using USB 2.0 hub/adapter/cable. Note that you will be unable to use USB 3.0 features on the devices under the troubleshooter
Minimal usage: launching driver only
roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch port:=/dev/<symlink_name>
# <symlink_name> : The same as above
Arguments
Check them by roslaunch power_switching_tools_ros usb_serial_troubleshooter.launch --ros-args:
Required Arguments:
port: Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
Optional Arguments:
init_with_power_on (default "true"): Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
init_with_power_set (default "true"): Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
power_cycle_interval (default "1.0"): Interval [sec] in USB power cycle using USB-Serial troubleshooter
power_cycle_service (default "~power_cycle"): Name of service for USB power cycle
power_service (default "~power"): Name of service for USB power switching
serial_timeout (default "1"): Timeout [sec] of serial communication with USB-Serial troubleshooter
Services
-
usb_serial_troubleshooter_driver/power(std_srvs/SetBool)Power on/off USB.
-
usb_serial_troubleshooter_driver/power_cycle(std_srvs/Trigger)Execute power cycle of USB.
Advanced usage: automated power cycle of USB
roslaunch power_switching_tools_ros auto_power_cycle.launch troubleshooter_port:=/dev/<symlink_name> monitored_topic:=<monitored_topic> monitored_topic_expected_hz:=<monitored_topic_expected_hz> monitored_topic_respawn_delay:=<monitored_topic_respawn_delay>
# <symlink_name> : The same as above
# <monitored_topic> : Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
# <monitored_topic_expected_hz> : Expected Hz of monitored topic
# <monitored_topic_respawn_delay> : For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
#
# In default, this launch firstly executes power cycle once. If you want to change this behavior, set "init_with_power_cycle:=false"
USB PPPS hubs
“PPPS” stands for “Per-Port Power Switching” which is an advanced functionality of USB hubs. Hubs supporting PPPS (e.g., VirtualHere USB 3 4-Port Hub) are listed here.
- Advantages compared with USB-Serial troubleshooter:
- Having multiple ports
- Connection problem does not occur
- Disadvantages compared with USB-Serial troubleshooter:
- Power switching is slower
- Some devices show unexpected behavior after you command your hub to power off them
- Power comes back on after few seconds
- Power comes back on when the device is accessed. This behavior was observed when webcams were used on Ubuntu 20.04 (not observed on Ubuntu 24.04). This behavior is slightly different from the first behavior because the first behavior depends on no external access. The workarounds for the first behavior on Ubuntu 20.04 (i.e., Linux 5.x) mentioned in the document do not work for the second behavior
Preparation
Udev setting
This is required for running the driver node without sudo.
```bash rosrun power_switching_tools_ros setup_udev_for_usb_ppps_hub
Reboot your PC after this script finishes
File truncated at 100 lines see the full file
Changelog for package power_switching_tools_ros
3.0.0 (2026-11-06)
-
[voicevox, chaplus_ros, emotion_analyzer, gdrive_ros, google_chat_ros, influxdb_store, power_switching_tools_ros, respeaker_ros, ros_speech_recognition, rospatlite, sesame_ros, switchbot_ros] depend on ros_environment for ROS2 buildfarm The buildfarm builds each package with only its own build dependencies, so without ros_environment $ROS_VERSION is empty and CMakeLists.txt takes the ROS1 branch (same as jsk_common#1835). voicevox also guesses ROS_VERSION from AMENT_PREFIX_PATH when it is unset. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] add ROS2 support Single package.xml/CMakeLists.txt branched on $ROS_VERSION, same as chaplus_ros and jsk_common's ROS2-ported packages.
- CMakeLists.txt: the ROS2 block is prepended and the ROS1 original is wrapped in else()/endif() unchanged (no re-indentation). The python package is installed with ament_python_install_package(), the driver scripts go to lib/ with jsk_ros1_ros2_compat_install_python() (python3 shebang, jsk-ros-pkg/jsk_common#1832; a ROS2-only buildtool_depend >= 3.0.2), and scripts/ and udev/ to share/.
- python: the original rospy code is kept as is for ROS1 users (PowerSwitchingDriverBase, UsbPppsHubDriver, UsbSerialTroubleshooterDriver and the __main__ blocks, used when jsk_ros1_ros2_compat, i.e. jsk_common >= 3.0, is not available), and PowerSwitchingDriverBaseCompat, UsbPppsHubDriverCompat and UsbSerialTroubleshooterDriverCompat are added next to them as the same code written with jsk_ros1_ros2_compat's rospy_rclpy_compat (init_node, spin, get_param, create_service, get_response_class, sleep,
log*, logfatal, get_name, signal_shutdown; jsk-ros-pkg/jsk_common#1831, >= 3.0.2), which run on both ROS1 and ROS2 when jsk_ros1_ros2_compat is available. Only the imports (rospy and std_srvs'*Responseclasses do not exist on ROS2) and the __main__ conditions of the original lines change. The compat version of the ~hub_location/~hub_port check also treats None as missing, since ros_compat.get_param() returns the default instead of raising KeyError.- auto_power_cycle.py and the launch files stay ROS1-only for now: it subscribes with rospy.AnyMsg and calls the power cycle service synchronously from a timer callback, which would deadlock a single-threaded rclpy executor. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>>
-
[power_switching_tools_ros] Add webcam problem to README
-
[power_switching_tools_ros] Add how to try latest uhubctl
-
[power_switching_tools_ros] Enable to set multiple hub_location and hub_port
-
[power_switching_tools_ros] Fix udev setting script
-
[power_switching_tools_ros] Add more document of power switching test
-
[power_switching_tools_ros] Enable to add supplementary options to uhubctl and specify path to uhubctl
-
[power_switching_tools_ros] Add another advantage of USB PPPS hubs
-
[power_switching_tools_ros] Enable to prepare multiple udev rules for USB-Serial troubleshooters
-
[power_switching_tools_ros] Support USB PPPS hubs
-
[power_switching_tools_ros] Make it easier to support new device
-
century_ros -> power_switching_tools_ros
-
Contributors: Kei Okada, Shun Hasegawa
Package Dependencies
| Deps | Name |
|---|---|
| catkin | |
| ament_cmake | |
| ros_environment | |
| ament_cmake_python | |
| jsk_ros1_ros2_compat | |
| python-serial | |
| rospy | |
| rclpy | |
| std_srvs |
System Dependencies
| Name |
|---|
| python3-serial |
| uhubctl |
Dependant Packages
Launch files
- launch/auto_power_cycle.launch
-
- monitored_topic — Topic monitored for determining health of monitored communication. If this is not published for an unusually long period, power cycle of that communication occurs
- monitored_topic_expected_hz — Expected Hz of monitored topic
- monitored_topic_respawn_delay — For this duration [sec] after power cycle, new power cycle does not occur to wait for topic to be published
- launch_default_driver [default: true] — Launch driver of USB-Serial troubleshooter
- troubleshooter_port [default: /dev/ttyACM0] — Port connecting with USB-Serial troubleshooter
- troubleshooter_serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- troubleshooter_power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- troubleshooter_init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by troubleshooter_init_with_power_on
- troubleshooter_init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when troubleshooter_init_with_power_set is true
- monitored_topic_allowed_delay_cycles [default: 2.0] — If monitored topic is not published in the expected timing and is delayed for ((1 / monitored_topic_expected_hz) * monitored_topic_allowed_delay_cycles) [sec], power cycle occurs
- init_with_power_cycle [default: true] — Execute power cycle when auto_power_cycle node is initialized
- launch/usb_ppps_hub.launch
-
- hub_location — Location(s) of USB PPPS hub (e.g., '3-5', '[3-5, 2-2]', , '[3-5, 3-5]')
- hub_port — Port(s) of USB PPPS hub you want to power on/off (e.g., '1', '[1, 1]', '[1, 2]'). Must be the same length as hub_location and each element corresponds to the element at the same position in hub_location
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB PPPS hub
- init_with_power_set [default: true] — Set power state of USB when driver of USB PPPS hub is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB PPPS hub is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle
- uhubctl_executable [default: uhubctl] — Command to control USB PPPS hub. You can add supplementary options to uhubctl command (e.g., 'uhubctl -r 100'). In addition, you can specify the path to uhubctl command you installed on your own (e.g., '~/uhubctl/uhubctl')
- launch/usb_serial_troubleshooter.launch
-
- port — Port connecting with USB-Serial troubleshooter (e.g., '/dev/ttyACM0')
- serial_timeout [default: 1] — Timeout [sec] of serial communication with USB-Serial troubleshooter
- power_cycle_interval [default: 1.0] — Interval [sec] in USB power cycle using USB-Serial troubleshooter
- init_with_power_set [default: true] — Set power state of USB when driver of USB-Serial troubleshooter is initialized. Which state (ON or OFF) is set is defined by init_with_power_on
- init_with_power_on [default: true] — Power on USB when driver of USB-Serial troubleshooter is initialized. This argument is valid only when init_with_power_set is true
- power_service [default: ~power] — Name of service for USB power switching
- power_cycle_service [default: ~power_cycle] — Name of service for USB power cycle