-
Notifications
You must be signed in to change notification settings - Fork 938
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GSoC 2022: Simultaneous Trajectory Execution #3156
Comments
Summary of changes introduced in Draft PR:
*Collision checking method: The current approach to checking collisions between two trajectories is point-by-point with the PlanningScene::isPathValid method. The level of details of each trajectory (# of points) is not changed. This is not an optimal way but it works in practice. Improving this collision check method is within the scope of this project. |
Pull requests related to this projectMain PRs:
Dependencies, fixes, and tutorial PRs:
Lastest edit (October 17th, 2022) |
I created an example environment here using a dual-arm panda robot. |
Summary of the last meeting (2022/07/22):We discussed the high-level design of the
The current state of the API:There are two approaches to execute trajectories:
The idea is to remove the Use cases:
Next steps:To keep the discussion focused, let's propose changes in small iterations (PRs):
@v4hn @simonschmeisser what do you think? |
Summary of the last meeting (2022/08/02):We discussed the high-level design of the trajectory execution manager API:
Additionally, we discussed the overlapping functionality that the new |
Summary of meeting (2022/08/16)We discussed the proposal described in cambel#2 We further discussed the design of the trajectory execution manager API:
We discuss a solution to #3188:
|
Summary of meeting (2022/08/23)We discuss the design of the event-based trajectory execution manager API:
The latest version of the API is here cambel#3 |
State of development (2022/09/10)The changes are being tracked in cambel#3 While the initial goal of this project was to add the feature of simultaneous execution of trajectories, the current implementation seeks to have a unified backend to handle the current blocking execution mode and the simultaneous execution mode. To that end, an event-based approach is being implemented, as mentioned in the previous comments on this thread. Additionally, in simultaneous execution mode, support for To activate the new simultaneous execution feature, a dynamic reconfigure variable A demo can be found here Some tests have also been added. |
Summary of meeting (2022/10/04)We discuss the next steps to work on:
|
Final reportThe new feature developed here enables simultaneous execution of trajectories in MoveIt, so long as each trajectory uses a different set of controllers. For example, in a dual-arm environment, each arm can execute a different set of trajectories without needing to manually synchronize the motion of both arms into a single trajectory or wait for the other arm to finish moving. A collision check is now also performed right before the execution of new trajectories to prevent collisions with active trajectories. The simultaneous execution feature and the extra layer of collision checks can be enabled or disabled through dynamic reconfigure parameters. Example use cases:
Feature description
SetupThe simultaneous execution feature is active by default. However, through the following dynamic reconfigure parameter, it can be disabled, /move_group/trajectory_execution/enable_simultaneous_execution. The TrajectoryExecutionManager API remains the same for execution in blocking-mode:
For execution in simultaneous-mode:
Changes to the API
MoveItCPPIn simultaneous-mode, when multiple trajectories are executed in non-blocking mode Move Group Action ServersTo allow simultaneous execution of trajectories through the Code reviewThis feature is currently being tracked here #3243 Limitations
|
Thank you for your reworking efforts. As you pointed out, the implementation of continuous execution was somewhat broken. However, it provided a critical functionality that is important in some use-cases: The ability to update running trajectories on the fly with continuous planning approaches. Unfortunately, as I pointed out in #3252, this functionality has been removed as part of this rework. Will this be part of the final API again? From your explanations, this is not clear to me yet. |
I would love to work on this project, can you assign me |
This issue is about the GSoC 2022 project that I am working on with the guidance from @simonschmeisser and @v4hn.
Motivation and goals
This project is motivated by the desire of controlling several robots simultaneously while taking advantage of the planning and collision checking provided by MoveIt.
The main goal of this project is to complete the Simultaneous Trajectory Execution PR started last year to the point that it can be merged with MoveIt's mainstream code.
The subgoals are:
Further details of the implementation of this project will be added to this issue. Feel free to propose or discuss ideas relevant to this project on this issue.
Documentation
Links
The text was updated successfully, but these errors were encountered: