Hello there, I'm Mohamad Ayman a Computer Engineering Masters student and a Google Summer of Code student.
My proposal this summer focuses on improving the Setup Assistant by automating the generation of some configurations and adding more GUIs to make the generation of some easier and more straight forward, along with improving the integration with Gazebo where we one wont have to add configs or edit the robot file manually for it to work with gazebo.
Below are the description of the improvements broken into tasks, I will update the tasks each time a related PR is opened, any suggestions or feedback are highly appreciated.
Project description on Google Summer of Code website.
[x] New screen for automatically generating interfaces to low level controllers
PR Setup assistant automating generation of controllers configs
pull request #951
pull request #994
[x] Improving gazebo integration.
pull request #956
pull request #936
[x] Perception screen for using laser scanner point clouds.
pull request #969
[x] New grasping screen for setting up end effectors.
[Blocked for now because the backend is still not ready]
[x] Parse existing text files [launch/config/package] and adding more GUIs for loading and saving settings.
[Basically each of the previous points contribute to this point]
[x] others
#1022
#1017
#1013
#995
#924
#1020
I'm not aware of the details of the GSoC assignment, so this is just a thought and may be already covered by some other requirement / idea (and something I've played with in the past): it might be nice to make the SA plugin based, where the overal UI and IO framework is provided by the SA, but plugins contribute the actual screens of the wizard.
My primary motivation for that was (now describing a situation in the past) a use-case we had in a project where we extended MoveIt with specific functionality that the SA had no way of configuring for. Instead of forking, a plugin-based approach allowed to provide just a single screen in a $project_moveit_setup_assistant_plugin package which was automatically discovered and loaded (using the regular pluginlib infrastructure).
One example is a SA screen that uses an interface to a particular industrial robot controller and shows a UI to import all 'home positions' defined on that controller as named states in a MoveIt configuration by clicking a button.
To make the SA plugin based does actually sounds like a very nice idea.
But I think it is gonna need some careful planning and more descion, I believe it would be best if I were to finish the main points of the project like improving the gazebo integration, in the mean time we would be discussing the idea and how to accomplish it.
What do you think?
@davetcoleman
We are about to start working on our own "mikado_setup_assistant" (name not final) for our software, sharing plugins either way sounds like a great idea! (I.e. having a plugin system should hopefully also allow loading these in a different host application)
@MohmadAyman I would say the plugins should be a lower priority than the other features we are focusing on, but if there was time at the end of the summer then of course it sounds great
Hi @simonschmeisser , have you guys started working on your "mikado_setup_assistant"?
@MohmadAyman no, not yet. I cannot really give a prediction yet when we will either
@MohmadAyman please update this issue with your final updates, then we should consider closing it
Done,
Can we leave it until the tutorials have been updated? so they don't get forgotten.
I believe this can now be closed. Congrats @MohmadAyman for a very successful GSoC project! Your continued involvement in MoveIt! including code review and code contributions are always welcomed :100:
I've opened a PR for the Plugin based SA #1243 , would be nice to have your input.
Most helpful comment
I'm not aware of the details of the GSoC assignment, so this is just a thought and may be already covered by some other requirement / idea (and something I've played with in the past): it might be nice to make the SA plugin based, where the overal UI and IO framework is provided by the SA, but plugins contribute the actual screens of the wizard.
My primary motivation for that was (now describing a situation in the past) a use-case we had in a project where we extended MoveIt with specific functionality that the SA had no way of configuring for. Instead of forking, a plugin-based approach allowed to provide just a single screen in a
$project_moveit_setup_assistant_pluginpackage which was automatically discovered and loaded (using the regularpluginlibinfrastructure).One example is a SA screen that uses an interface to a particular industrial robot controller and shows a UI to import all 'home positions' defined on that controller as named states in a MoveIt configuration by clicking a button.