MoveIt has grown in many ways, some good and some bad. We are worried that this growth has resulted in some stagnation and difficulty in making large changes that would add value. To that end the maintainers of MoveIt met and made this plan to spur future development:
Do exercise where we design MoveIt with our experience as if it doesn’t exist. This should educate a roadmap of features, refactors.
A drive to simplify and clarify the interfaces and levels of abstraction. We recognize the library has grown in complexity to the point where none of us understand it fully.
Defining what is MoveIt to educate what belongs and what doesn’t.
Discuss in GitHub issues parts of MoveIt we are confused about why they are part of the library and consider removing them.
Old features that are sufficiently superseded by newer features should be removed to reduce the complexity of MoveIt.
Sounds awesome! Personally, I’d love to see a design that focuses on providing an awesome C++ library first, and then everything else - a ros node, anything that forces a threading model, anything that reads ROS params directly, etc, would be there mainly as an example of how to use that C++ library. I know there has bee a lot of effort to provide good low level, thread-model agnostic C++ library functions and classes, but it often feels like the most supported and common way to use moveit is to instantiate a big high level thing (like a PlanningSceneMonitor) and then poke it with a stick.
It’s not that I want to use the library without ROS necessarily (although other people may want to do that). I’d just like to make things as debuggable as possible. When I create a PlanningSceneMonitor and it creates a PlanningScene and that creates some other class which reads some ROS param from the global ROS parameter server that I have no idea exists, that is super hard for me to debug. I’d much rather instantiate things at top level and use dependency injection to pass them in as needed. Those things I instantiate at top level may still read ROS params, but it will at least be much more obvious when they do. And when I want to write code-only unit tests, I want to be able to bypass all parameter loading and manually set all parameters at the top level.
(bad example since i think the PlanningScene itself doesn’t read ROS params, but the idea is that loading ROS params creates hidden state the user has to reason about on top of the arguments of the function/class)
Gripper control: No robot arm is used without gripper and gripper interface is not so great today. I would define an interface that would allow high level control e.g. gripper.close() and test gripper.gripped() -> bool and a simple Open/Close button in the GUI. Maybe a joint work with ros-end-effector ?
Cycle: I think there’s a missing concept of Cycle on top of the Trajectory concept, that could be something like a GRAFCET/state machine and that could be stored in a ROS message and also be sufficient to represent a full robotic task: sequence of trajectories/goals and transistions to be verified to skip to the next.
Less code: I think that ROS should embrace engineers that are not programmers, e.g. process engineers, that would be a great argument to propel ROS in industrial teams where they is no computer scientist yet. This requires using ROS with less code. I like Intera or UR Polyscope, I think the graphical ways they represent cycles are good. I had plans on working on such prototype some day, based on Blockly on top of MoveIt.
Trajectory Constraints: I would allow the user to provide **contraints for trajectory planning via interactive markers, feeding trajectory constraints such as in moveit_msgs/PositionIKRequest.constraints and/or refine computed trajectory to change intermediary arm configurations…
I think MoveIt misses some trajectory database, starting along Move group, that could store computed trajectory, both from:
the GUI ; with a new button Store as MyTraj1 and Play MyTraj1). Some feature like Reach initial point from MyTraj1 might also be interesting
the code ; with a clearer separation between the planning vs deterministic environments: respectively the trajectory generation framework / OMPL vs deterministic trajectory record/replay. For example commander.plan() would belong to the first while commander.execute() would belong to the second.
As you can see I attach a great importance to the GUI: even if it cannot be as powerful as custom code, it should cover as many programmatic features as possible to give users, and especially people who dislike code, at least a wide overview of MoveIt features. This way MoveIt could compete with industry products such as RoboDK. Some of my colleagues disagree with me on that point because they think ROS should not address regular robotics e.g. pick-and-place but should focus on future complex tasks that necessarily require custom code e.g. wheeled manipulators in complex environments.
Some of my points might be already solved by MoveIt today (e.g. by the warehouse? But I’m a bit unaware about it, its goal and usability from Python) so forgive me if it’s already capable of these
I remember an hour long (longer?) session of brainstorming at the MoveIt session at ROSCon in Macau, which resulted in an almost endless stream of post-its on several walls.
Some of that went into the roadmap doc on the website, but the rest is difficult to find.
Could we start from what came out of that session instead of from scratch?
The brainstorming session at ROSCon Macau was useful for gathering ideas for what is missing / could be improved in MoveIt, but that tends to focus on features. We also want to revisit the overall architecture of MoveIt, the core concepts, and potentially get rid of extra cruft.
rename things to make it easier to learn & teach. (why is the main node called “move_group”, that name is also used for a collection of joints?!)
drop anything related to openrave, and maintain a new version of IK Fast. Currently, people rely on docker, old generated code, or other crazy things to make them usable
I think part of MoveIt’s complexity is caused by these two (conflicting?) goals:
“An awesome C++ library first”
Strong focus on GUI, Python interface, “out of the box solution”, …
Although an awesome C++ library can have an awesome Python interface I think!
When focussing on the first goal, I think these things could help MoveIt to implement the state of the art in motion planning (if that is a goal):
Automatic differentiation support for kinematic expressions. This is especially useful for optimization-based planners.
Scene graph support (in combination with making it easier to check collision for individual links in this graph).
Cleanup inverse kinematics interface (see this talks by Robert Haschke).
But this can also be interpreted as just my personal wishlist
Edit
One final thought. If we can think outside the box, why not use a C++ alternative such as rust. I’ve heard good things about it, but I suspect MoveIt has important external C++ dependencies such as OMPL that would make a switch very hard.
I think this is a complex but important point. Personally I feel like it is close to impossible to avoid programming skills to implement custom automation solutions. Is code not just a more efficient way to communicate highly custom requirements compared to a GUI interface? This does not mean there is no room for GUI based software in certain field or for specific applications of course.
But maybe this discussion is slightly off-topic here, although is directly related to the question “who is the intended MoveIt user?”
(*disclaimer, I’m a PhD student and in general quite far removed from industry, although some of my advisors are from industry.)
I would like to see the moveit_fake_controller_manager get removed. It’s not necessary anymore with the fake_joint_driver package and causes a lot of confusion, IMO.
I agree this is a problem. I’d like to see moveit be much more testable. If you’d like to help find ways to do this I’m happy to help us get there. I’ve been trying to improve the testing of MoveIt for a while and changing the architecture to make it more testable would be very welcome.
:
