[pull] master from ros-planning:master #459
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Standalone applications used the convenience function moveit_warehouse::loadDatabase() to load a database plugin. Internally, this uses a static plugin loader. As this static variable is released too late during app shutdown, we get an exception: ``` terminate called after throwing an instance of 'class_loader::LibraryUnloadException' what(): Attempt to unload library that class_loader is unaware of. ``` Explicitly instantiating the loader ensures correct destruction order and avoids the error.
The old implementation used a RobotState instance for considered_start_state_, which was transformed into a RobotState message, when filling the actual MotionPlanRequest. This turned a provided diff message into a full message, which has performance drawbacks when there are many large attached object meshes. The new implementation uses the message format directly, avoiding unnecessary conversions. Co-authored-by: Robert Haschke <[email protected]>
…cific timestamps (#3580) This commit introduces: 1. per-group current state time retrieval 2. per-group complete robot state waiting This fixes the following issue: I want to call waitForCompleteState on group_A, which the API already supports. There is also another joint out_of_group_A in the robot model that is not available until some time after bringup. I'm calling waitForCompleteState(group_A, <timeout>) way earlier than out_of_group_A is published by its source. The problem with the current implementation is that it waits until <timeout> elapses, but returns true since all joints of group_A exist. I don't see a point in waiting for an out-of-group joint in this case.
…State (#3590) CommandListManager::setStartState shall update the start state in the next MotionPlanRequest to match the reached robot pose after previous planning steps. Copying attached collision objects is not necessary there, because the RobotState is initialized once in the beginning. In each iteration of CommandListManager::solveSequenceItems(), only joint states actually update. Copying the attached bodies is not only a performance penalty, but also introduces a (numerical) drift of the attached object poses as pointed out in #3590 (comment) / #3569. Co-authored-by: Robert Haschke <[email protected]>
* github.com/ros-planning -> github.com/moveit * codecov.io/gh/ros-planning -> codecov.io/gh/moveit * ros-planning.github.io -> moveit.github.io
After Plan+Execute, the joints tab switched back to the start state model because onFinishedExecution() updates this state to the current one usually. Hence, it was the last model modified... Ensure that the goal state gets updated in any case.
* Fix constrained-based planning Constrained-based planning enables the PoseModelStateSpace by default, meaning that state samples are created by sampling in SE(3) and then performing IK. This state space frequently caused issues, eventually leading to the introduction of the ROS parameter enforce_joint_model_state_space in PR #541 as a work-around. A more detailed analysis shows that the state space's interpolation approach is the culprit - performing interpolation in Cartesian space. If the two interpolation ends are close in Cartesian but distant in joint space, the interpolated state (obtained from IK) can be far away from both start and end (particularly for redundant arms), while its Cartesian pose is naturally close to both interpolation states. This will lead to consecutive waypoints being close in Cartesian space but distant in joint space. If such a trajectory is executed, the controller will interpolate in joint space, leading to a large and unchecked motion. To avoid this issue, interpolation should be performed in joint space during planning as well. The only drawback of this change is that trajectories are less linear in Cartesian space. However, as the trajectory is random-sampled anyway, this shouldn't be a big issue. * PoseModelStateSpace: Use joint-space distance Configurations may be similar in Cartesian EE pose, but very far apart in joint space. What actually matters when connecting states is the joint-space distance.
... when no IK solver is defined for the planning group
* Prevent segfault when getParentLinkModel() is NULL * Simpliy code * Add unit test operating the panda gripper --------- Co-authored-by: Captain Yoshi <[email protected]>
As the CHOMP planner only considers active joints, it needs to use setJointGroupActivePositions() instead of setJointGroupPositions().
Don't recreate the FCL object when moving shapes, but just update its transforms.
The Pilz planner generated trajectories with identical subsequent time stamps, which were rejected by the ROS controllers. Pilz's appendWithStrictTimeIncrease() function had a single if-statement that encompassed two conditions: 1. trajectory is empty 2. the end state of one segment differs from the start state of the next segment In both cases, the whole trajectory segment was appended with a dt=0. However, that's correct only for case 1. In case 2, we needed to apply a non-zero time offset dictated by the actual dt of that segment's first waypoint.
* Deprecate JumpThreshold-based computeCartesianPath() * Remove deprecated methods RobotState::computeCartesianPath() * Replace deprecated functions
* cleanup after actionlib fix actionlib was fixed via ros/actionlib#156 * Reset status variables before calling sendGoal() This fixes a race condition, where the execution status is set to RUNNING after the doneCallback has been called, e.g. because the controller immediately reports success.
#3615 made PoseModelStateSpace identical to ModelBasedStateSpace, both using joint-space interpolation and distance measurements. This resulted in planning timeouts for code that previously worked. Obviously, using joint-space interpolation much more often results in the rejection of tight path constraints than Cartesian interpolation did. The problem with potential jumps due to Cartesian interpolation in principle remains, which is a dilemma of the current design: - We do need Cartesian interpolation to reduce the risk of state rejection due to a failing path constraint, which currently cannot be checked during interpolation. - Ideally, we would do joint interpolation and only resort to Cartesian interpolation if the path constraint is violated, i.e. follow a similar approach as in #3618. However, this would require access to the path constraint...
The tolerance of orientation constraints needs to be interpreted w.r.t. the given frame_id of the constraint instead of the target frame. Not doing so, a large tolerance is interpreted about the wrong axis and resolving constraint frames fails. Unfortunately, the proposed approach only works for the ROTATION_VECTOR representation.
) The ResolveConstraintFrames adapter was only changing the planning request used within the planning pipeline, while the subsequent trajectory validation was still using the original, unresolved request, causing at best a warning and at worst acceptance of paths not satisfying the path constraints. We make the adapter obsolete and just call the resolver function once in the beginning of the planning pipeline.
back-port of moveit/moveit2#1813
Newer versions of gtest verify that registered tests are instantiated. As only test_fcl_collision_detection_panda.cpp instantiates the distance tests, they should be registered only there.
ros.rosconsole_bridge.class_loader.ClassLoader: SEVERE WARNING!!! Attempting to unload /opt/ros/one/lib//libprbt_manipulator_moveit_ikfast_plugin.so while objects created by this library still exist in the heap! You should delete your objects before destroying the ClassLoader. The library will NOT be unloaded. We need to delete the RobotModelLoader after the RobotModel.
long after changing the value...
Backport of moveit/moveit2#3183 Co-authored-by: Jafar Uruç <[email protected]>
Updated a comment on line 136 per issue #3358 Co-authored-by: Michael Görner <[email protected]>
- Return the oldest time a joint from the group was updated - If joints never received an update, the return value should be zero - Joint updates received via tf_static should be always considered recent Co-authored-by: Robert Haschke <[email protected]>
In support of #3674, I've added functionality to the mesh_filter to create links from primitive shapes, not just from meshes. Co-authored-by: v4hn <[email protected]>
) This allows parallel execution + planning. Also required modifying updateSceneWithCurrentState() to allow skipping a scene update with a new robot state (from CurrentStateMonitor), if the planning scene is currently locked (due to planning). Otherwise, the CurrentStateMonitor would block too. Co-authored-by: Robert Haschke <[email protected]>
Simplified Backport of moveit/moveit2#3187 Co-authored-by: v4hn <[email protected]>
The previous value of 0.9 is not actually very transparent and can introduce rendering artifacts.
... as we dropped Melodic/Bionic support in #3677
20.04's version of clang-format-12 is 12.0.0, which is broken. 22.04's 12.0.1 version works fine.
* QRegExp has been removed in Qt6 * No longer need to add std::string as QMetaType * QStringRef was removed in Qt6 * Use modern Qt connect syntax * QComboBox::currentIndexChanged(QString) is gone in Qt6 * currentIndexChanged(QString) and modern connect Co-authored-by: Robert Haschke <[email protected]>
Co-authored-by: Robert Haschke <[email protected]>
* Move update of state_update_pending_ to updateSceneWithCurrentState() * Revert to try_lock While there are a few other locks except explicit user locks (getPlanningSceneServiceCallback(), collisionObjectCallback(), attachObjectCallback(), newPlanningSceneCallback(), and scenePublishingThread()), these occur rather seldom (scenePublishingThread() publishes at 2Hz). Hence, we might indeed balance a non-blocking CSM vs. missed PS updates in favour of CSM. * Don't block for scene update from stateUpdateTimerCallback too The timer callback and CSM's state update callbacks are served from the same callback queue, which would block CSM again. * further locking adaptations reading dt_state_update_ and last_robot_state_update_wall_time_ does not lead to logic errors, but at most to a skipped or redundant update on corrupted data. Alternatively we could be on the safe side and turn both variables into std::atomic, but that would effectively mean locks on every read. Instead, only set state_update_pending_ as an atomic, which is lockfree in this case. Co-authored-by: Michael Görner <[email protected]>
The shared pointer is just not needed and triggers an (unnecessary) copy of the object in setObjectPose(). Fixes #3691.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )