World's should be allowed to be more than singular, but either every object created should be created with a world OR there should be a way of getting the current world for an object.

Basically, worlds should act like singletons MOST of the time, so their constructor should replace the activeWorld with the most recently constructed one.

This means you CAN create more than one in theory, but if you just want the active one, you can always call getActiveInstance on the class.

The constructor may need a mutex to make this truly safe, but for now we will ignore that.

Required for issue #1
Add a unique identifier for each grasp as it is planned so it can be found later. Also mark each grasp as untested as it is planned, so that it's status can be tracked.

required for issue #1 ClientSocket needs an analyzeGrasp method that sends a string and the grasp.

To be useful, it also needs a signal in the ivmgr class similar to the processWorldPlanner signal. Call it analyzeGrasp also. It then needs to be connected to an analyzeGrasp method in the constructor.

The signal should be emitted by addUniqueSolution method after the grasp is added to the list in egPlanner.cpp,

Required for #8 Right now, grasp messages do not have any identifier, they just spit out a list of numbers.

Similar to the way the Robot class has a setTransparency, it should have a setEmissiveColor or maybe a more general setColor with an enum for the type of color to change.

align, rotateHandLat and rotateHandLong have no real place in the ivmgr. Move them to the the view controller for the bci experiment.

Need a test for point cloud rendering implemented in pull request #60

It appears that the grasp transforms sent are currently incorrect.

currently we transform the pointcloud data before sending to graspit, we just send the tf, and then let graspit put the pointcloud in whatever frame it likes.

The whole system needs much more robustness to our of order communications.

Requests while the connection is being made

Multiple grasps being recieved at the same time for analysis (currently fails because graspit requests the current hand pose while processing each grasp, which causes interspersed communication.

Restarting graspit while the graspit_python_node is running fails because the existing target state is not reiterated. This causes problems with the point cloud showing in graspit.

Restarting the graspit python node while graspit is running because the target state is not reiterated.

Restarting the arm planner while graspit is running fails because the model list is not persistent and because the target state is not reiterated.

Test each of the drawing primitives using #38

We don't want to have a million sockets, so we need some way to send multple message types on a single socket. See http://eli.thegreenplace.net/2011/03/20/boost-asio-with-protocol-buffers-code-sample/ for more details

This issue can be broken down in to four parts:
1 - Modifying the grasp planner to have a unique identifier for each grasp and a 'tested' attribute for each grasp. Testing the reachability is going to happen in a asynchronously different program, and we don't want to have to pass back the entire grasp description with the results to go looking for it.

2 - Modifying the grasp_message_robot_server node in the trajectory_planner package to actually do the test.

3 - Modifying graspitServer.cpp to accept a message with the grasp identifier and result of the test

4 - Modifying the eigengrasp planner to either remove those grasps without hitting race conditions while modifying the grasp list.

Depends on #23
Right now, the objects all move to center the target object at (0,0) -- The z axes remain unchanged

This should happen. Instead, the axes should get drawn around where the object actually is.

We want a fake graspit node that sends out precanned requests.

Finish #37 -- connecting the drawing commands
Finish #38 -- writing a testing client for protobuf messages
Finish #39 -- start a protobuf server
Finish #40 -- Test drawing commands

We need a test node that takes the place of model rec and just spits out a precanned answer.

in include/searchStateUtils.h
the << operator should send that s->getObject()->getName() first.

This method should replace every since instance of graspitGUI->getIVMgr()

The egPlannerDlg was never intended to be used this way, we just completely hijacked it. This should be undone. The bci experiment should get its own files and stuff.

Required for #8 Requests while the connection is being made

graspitServer should get an interface to set the emissive color of a robot or body
so that we can indicate things like reachability or that a body is blocking access from a given direction.

Depends on #25

Look at the way that a new GraspitSocketServer is made. Do the same thing for the protobuf server.

It should probably use socket 4766, since the graspitsocketserver uses 4765

Write a test client in python that cans end protobuf messages to the protobuf server. Put it in a new directory named scripts/testing_tools

Look at https://github.com/jon-weisz/graspit_bci/blob/implement_ui_drawing/src/graspitProtobufServer.cpp

The protobuf server needs to emit a Drawable protobuf message when it recieves one and the binary_message_ui needs to connect a slot somewhere to recieve it.

Required for issue #1
The Graspit Socket server should accept a SetGraspAttribute grasp_identifier attributeString float_value command that looks at the currently running planner, finds the identified grasp if possible, and sets the given attribute to the given value.

Right now the X and Z axis guides are always around the (0,0,0). Instead, they should be drawn around the object itself - preferably around it's center (not it's origin)

The point cloud rendering in graspitServer.cpp is a huge hack
It needs to be rewritten so that it doesn't create a whole new subgraph every time a point cloud comes in.
Instead it look up the appropriate nodes and only create them as needed.
Additionally, it should get a transform node, so that outside observers don't need to transform it for us.

The online planner reranks grasps and is supposed to maintain one list of grasps that is implicitly divided in half.
The first ten grasps should be those that are already analyzed for reachability, if they are successful
The second ten grasps should be those that have not yet been analyzed.

It is important that we reserve space for grasps that have not been analyzed so that they are not permanently rejected in favor of those that have been.

We need to implement point cloud drawing using the protobuf structured messages.

The online planner's updateSolutionsList function should respect test failure by pausing the grasp to the end of the list. The hand view window should ignore grasps that fail the test