Manipulation WG / MoveIt Maintainer Meeting - October 26

MoveIt
1

The next Manipulation WG Meeting / MoveIt Maintainer Meeting will be 2023-10-26T15:00:00Z.

Agenda

Meeting

Dial in by Phone (US)
+1 406-851-5227
PIN: 490 349 699#

2

Attendance:

  • Abishalini Sivaraman
  • Cassidy Elliott
  • Chance Cardona
  • Sebastian Castro
  • Sebastian Jahr
  • Marq Rasmussen
  • Tyler Weaver
  • Mario Prats
  • Henning Kayser
  • Nathan Brooks
  • Paul Gesel

Agenda:

[Henning] Discussion of new logging changes

  • Changes to get logging publishing to /rosout
  • need to associate all loggers to node instances
  • Tyler’s worked on PRs to implement this
  • PR need reviews
  • [Tyler] will write up a concept guide on logging changes that have been made, but no changes to API interface so shouldn’t need migration notes

[Sebastian C] Tool changing API

  • We have some existing work from Jafar on tool changing: GitHub - PickNikRobotics/tool_changing: MoveGroup capability to dynamically change end-effectors
  • The way it works: have a Robot that already has many tools attached to it in its description, and then virtually adds/removes tools by changing the allowed collision matrix and what is visualized in rviz (visualization is currently broken though)
  • [Nathan] Limitations:
    • Problem with how visualization updating in RViz works
    • Cannot currently update kinematic aspects online with this approach
  • Want to be able to actually change the URDF during execution and
  • [Marq]: need to be able to dynamically power up and power down interfaces like the robotiq gripper power&comms: will need to make ros2 control changes. May make more sense to just re-initialize MoveIt instance rather than making all the interfaces support some dynamic robot description change
  • [Henning]: Is it MoveIt’s responsibility to support changing tools and providing a dynamic robot model? It has access to ros2 control interfaces so this should be feasible
  • [Marq]: Yes, otherwise we’ll need an orchestrator on top of MoveIt
  • [Sebastian C]: Use case: bi-manual task. one arm holds something (jaw gripper), one arm cuts. Need to swap cutting tool to make different cuts
  • [Nathan, Henning, Tyler] Should have what tools we’ll be using be preconfigured.
  • [Marq]: More layers of complication: configuring/calibrating tools accordingly once they are attached. This cannot be pre-configured
  • [Nathan]: The current solution (Jafar’s) may still be able to solve Seb C’s application. Just assume an initial tool state once comms are attached
  • Relevant issues:

[SebastianJ]: Planning Adapter refactoring

  • Slides - design presentation
    • Looking for reviews on this work
  • [Mario]: Who defines the planning pipeline?
  • [SebastianJ]: defined in ompl yaml file at startup: https://github.com/sjahr/moveit_resources/blob/pr-update_pipeline_planner_configs/panda_moveit_config/config/ompl_planning.yaml#L4-L10
  • [Henning]: Previously an adapter could be called both before and after planning, which was a feature, although it added a lot of complexity, but these changes limit that (now adapters can only be called either before or after)
  • [Mario]: Could we close the loop here from the user perspective: ex. manually call RRT plugin, then call a STOMP plugin on the response in a C++ interface?
  • [SebastianJ]: You could but it wouldn’t be convenient with the current infrastructure, the way things are setup it’s easier to create the entire vector of plugins
  • [Marq]: Could be useful to have something that cold starts plugins and appends the changed solution to the responses, but this starts moving into MTC territory