The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
I have been involved in the development of py_trees over the years:
Before it was released as open source, it was originally developed at Yujin Robot to handle the application layer of the fleet robots that they were developing. Among the original goals were:
It took a few iterations to get there, but ultimately we met all of our goals. We even found that the control engineers started moving their decision making logic to the behaviour trees when it didn't have low-latency requirements (e.g. docking) simply because it got their components into a framework which was monitored, logged, mocked and allowed them to interact with other parts of the robot (e.g. the notifications subsystem) without having to drag that subsystem in as a dependency for the control module (e.g. docking LED or sound notifications as it passed through different states in the docking process).
These days it has been picked up by CARLA for their scenario layer in driving simulations and Toyota Research Institute is doing the same internally. Blue Ocean Robotics has been using it for a while and I have been notified of a few other robotics companies in the valley area taking advantage of it, but I do not know to what extent.
| | 2 | No.2 Revision |
I have been involved in the development of py_trees over the years:
Before it was released as open source, it was originally developed at Yujin Robot to handle the application layer of the fleet robots that they were developing. Among the original goals were:
It took a few iterations to get there, but ultimately we met all of our goals. We even found that the control engineers started moving their decision making logic to the behaviour trees when it didn't have low-latency requirements (e.g. docking) simply because it got their components into a framework which was monitored, logged, mocked and allowed them to interact with other parts of the robot (e.g. the notifications subsystem) without having to drag that subsystem in as a dependency for the control module (e.g. docking LED or sound notifications as it passed through different states in the docking process).
These days it has been picked up by CARLA for their scenario layer in autonomous driving simulations and Toyota Research Institute is doing the same internally. Blue Ocean Robotics has been using it for a while and I have been notified of a few other robotics companies in the valley area taking advantage of it, but I do not know to what extent. extent.
| | 3 | No.3 Revision |
I have been involved in the development of py_trees over the years:
Before it was released as open source, it was originally developed at Yujin Robot to handle the application layer of the fleet robots that they were developing. Among the original goals were:
It took a few iterations to get there, but ultimately we met all of our goals. We even found that the control engineers started moving their decision making logic to the behaviour trees when it didn't have low-latency requirements (e.g. docking) simply because it got their components into a framework which was monitored, logged, mocked and allowed them to interact with other parts of the robot (e.g. the notifications subsystem) without having to drag that subsystem in as a dependency for the control module (e.g. docking LED or sound notifications as it passed through different states in the docking process).
These days it has been picked up by CARLA for their scenario layer in autonomous driving simulations and Toyota Research Institute is doing the same internally. Blue Ocean Robotics has been using it for a while and I have been notified of a few other robotics companies in the valley area taking advantage of it, but I do not know to what extent.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
