search

graspit-simulator / graspit

The GraspIt! simulator
http://graspit-simulator.github.io/
Other
180 stars 81 forks source link

GraspitGUI->GraspitCore #51

Closed jvarley closed 8 years ago

jvarley commented 8 years ago

Problem: Could not run graspit headless. ivmgr was doing way to many things, and this made it difficult to run headless. Ivmgr needed to do less, so that it is possible to run graspit without creating one.

Fix: GraspitGUI-> GraspitCore made it possible to run graspit without creating an ivmgr moved dbmgr, world ownership to graspitCore rather than ivmgr. added arg to be able to start graspit headless

Running headless: cd ~/graspit/plugins/openclose qmake-qt4 openClosePlugin.pro make -j5 cd lib export GRASPIT_PLUGIN_DIR=$PWD cd ~/graspit export GRASPIT=$PWD mkdir build cd build cmake .. make -j5 ./graspit_simulator --headless 1 -r Barrett -p libopenClosePlugin

This will cause graspit to run headless, load the Barrett hand, and then the plugin will print out "in main loop " over and over again.

jvarley commented 8 years ago

@mateiciocarlie @JenniferBuehler

thoughts?

mateiciocarlie commented 8 years ago

This looks great to me as a start, but won''t be able to look in detail until end of the week at best... It's definitely in the direction I was thinking about.

Now the dbasemanager is definitely an example of something that should be a plugin, or at least not part of the "core"... @jvarley - are you actively using it? What are your thoughts on putting it in a better place? Sorry to keep piling things on, but that will really clean up the graspitCore.

jvarley commented 8 years ago

I am not using CGDB at the moment. I completely agree that dbasemanager should be pulled out into a plugin somehow. I think that could be saved for another day though, as I am not really sure where to put it at the moment.

I am afraid to take it out at the moment, as I think we would also have to take out all the related dialogues menus. I don't think we want code depending on a plugin in the graspit code base. I think we could tackle that later on and come up with a way for a plugin to add new menu's to the UI. Then we could pull out ALL CGDB and database related code into its own plugin.

JenniferBuehler commented 8 years ago

Just starting to look at this now. I really like the idea to take the world object out of the IVManager.

I'm thinking that a good first approach to see whether this is working outside plugins as well is to test my grasp_planning_graspit package with the new GraspitCore. Will then report how it's working on that side - I can do a full EGPlanner run to verify it's working as expected.

First thought: I'd like to have another constructor of GraspitCore to take explicit parameters (instead of argc,argv), eg. a boolean for headless mode. I only need GraspItCore for the World object.

How would you like me to go about this, should I do my suggested changes and then submit a PR to your fork, @jvarley?

JenniferBuehler commented 8 years ago

Oh and, of course, I need it for IVmgr as well. I noticed that this is not merged with the abstract IV Manager changes yet (eg. HeadlessIVManager not there) - is this intended? Should we maybe merge it somehow, or am I right to assume this is a solution alternative to having HeadlessIVManager?

JenniferBuehler commented 8 years ago

Disregard my last question, I figured it out, it's a HeadlessIVManager alternative, obviously.

grasp_planning_graspit compiles now, but I have two issues which would need to be addressed (there may be more follow-ups as well but this could be it already):

  1. When saving a world with World::save(), the camera parameters are only read if ivmgr is not NULL. This writes a world file which cannot be opened with graspit_simulator. It would be good to be able to save world files in headless mode as well, even if it is with some constructed camera parameters (eg determined by BB). Should we add this somehow to GraspitCore?
  2. I need a possibility to create the graspit world explicitly, eg. via a function GraspItCore::createNewWorld() which would overwrite the initial world created in the constructor. I need to access the world from another thread than the thread which creates the GraspitCore and starts the main loop. Otherwise I get errors "QObject: Cannot create children for a parent that is in a different thread." To get rid of this, I need to create the world from the same thread which accesses it. I know this is awkward but this was the only way I found to run the IV loop in detached mode (not blocking the main thread). Can we add this feature? Overwriting/resetting the existing world can be an optional feature which does not have to be used (but which I would from grasp_planning_graspit).

Otherwise, looking pretty good so far. I have a branch in my fork (copy of @jvarley's headless branch) which I can use to do a PR. If you agree that I add above changes I can do this and we can discuss there.

I can work with the existing GraspitCore(argc, argv) constructor, it ain't so pretty to handle arguments this way, but I forgot it's necessary for the SoQt init etc.

JenniferBuehler commented 8 years ago

I only saw emptyWorld() later so point (2) above has been resolved.

See also my PR in your fork.

jvarley commented 8 years ago

@JenniferBuehler Any reason from your end to not pull this in?

JenniferBuehler commented 8 years ago

This works for me, so I'm good to go with this PR.

Summing up how I've used this PR: The EGPlanner can be run in headless mode with this. I'm still using my grasp_planning_graspit code (which runs it all in a separate thread, scene manager etc) but if the headless mode in GraspitCore was flawed, I could not have done the planning.

Your plugin code also works, so I'd say this is ready to go from my point of view.

jvarley commented 8 years ago

@mateiciocarlie This is ready. I think pulling the database manager can be saved for another pr, as I don't have a better place to put it at the moment.