search

cram-code / cram_highlevel

DEPRECATED. All the commits from here are in the corresponding cram2 repo: https://github.com/cram2/cram_plans, the specific costmaps and semantic maps are in their separate repositories, look in cram2 organization.
0 stars 3 forks source link

some porting to moveit issues #5

Closed gaya- closed 10 years ago

gaya- commented 10 years ago

I can't seem to find a message called moveit_msgs/CollisionMap. Did it get deprecated or are we missing something here. https://github.com/cram-code/cram_highlevel/blob/master/location_costmap/src/visualization.lisp#L74

fairlight1337 commented 10 years ago

Great. This is the reason why I'm hesitating to move to new versions. It was in groovy (moveit_msgs/CollisionMap), but apparently its gone again (hydro). I even wrote a plugin for rviz to use it for costmap visualization. So that's for the cat in hydro now. I can't seem to find whether there is an alternative right now. We're relying on the collisionmap for visualization purposes right now, nothing more - but this is still bugging me now.

fairlight1337 commented 10 years ago

Okay, I just found something suitable for replacement: costmap_2d/VoxelGrid This might be fitting better than the CollisionMap. I'll look into that, fix the deps for highlevel, and close the ticket once it's done. Thanks for bringing this up.

gaya- commented 10 years ago

Oh come on, they must've just renamed it in moveit, couldn't have been such a drastic change, could it? Because costmap_2d is from the navigation stack and that's yet another dependency. I personally don't have that stack installed at the moment. Actually, if there was something standard to go with this not connected to either moveit or navigation that would've been the best...

fairlight1337 commented 10 years ago

Actually, it looks like its not there any more: https://github.com/ros-planning/moveit_msgs/tree/hydro-devel/msg

Maybe I missed it and its hiding somewhere, but I have to give them credit: I don't see a real use for it there as well. So having the costmap_2d solution in place solves a bunch of problems:

  1. "CollisionMap" refers to a map describing collision entities. This is actually not was I wanted to really use it for. I just took the easy path there (which worked, luckily :+1: )
  2. Costmap2d seems to supply a designated communication means for doing what we'd need for visualization, and seems to be made for the purpose.

So, yeah, it does introduce a dependency - but I don't see a big problem there. I also don't see an issue with installing stacks (you install KnowRob just in order to use json_prolog, which is a pretty big dependency of CRAM). If there's a stack that has the stuff in it we might use, why not go for it? I would have preferred to stick with the moveit-solution, but that seems to be gone. Please prove me wrong on this point, but right now I don't see that coming :).

fairlight1337 commented 10 years ago

By the way, they actually removed (not moved) the message: https://github.com/ros-planning/moveit_msgs/commit/b1d5a36a08eeb3a7691b4efd0c689357fbe8504c

gaya- commented 10 years ago

Well, the thing with KnowRob is a bit different. We're actually depending on json_prolog such that we'd be able to communicate with KnowRob. We're using the semantic map of the kitchen provided by knowrob in cram_physics. And i think we want to extensively use knowrob in future, so i guess it's ok to depend on it... But yes, I'll try to find something similar to costmap_2d the next couple of days, and if I fail then you win and I agree with using its CollisionMap :)

By the way, they actually removed (not moved) the message:

Hmm, not the best commit message in the world, is it. They could've at least vaguely explained what's happening...

fairlight1337 commented 10 years ago

Deal! :)

moesenle commented 10 years ago

Finally, I have a few comments as well :)

I used the collision map just for debugging my probability distribution functions for designators and I stop using them as soon as I had my own OpenGL based visualization. The code Gaya found is sort of a pretty old relict from the early days when we started to use cram on Rosie. Given my OpenGL visualization works, I think you can just get rid of the debugging code in location_costmap.

On Sun, Dec 15, 2013 at 4:06 AM, Jan Winkler notifications@github.comwrote:

Deal! :)

— Reply to this email directly or view it on GitHubhttps://github.com/cram-code/cram_highlevel/issues/5#issuecomment-30597046 .

gaya- commented 10 years ago

So you mean the vizualisation.lisp is outdated? And in any case, what if some people would prefer using rviz for visualizing to OpenGL stuff? The problem with OpenGL is that you'd need the whole cram_physics stack for it...

gaya- commented 10 years ago

And, I just remembered that Jan wanted to use interactive markers for interacting with the robot in the pick and place scenario. So, if rviz is going to be our GUI, I guess we'll still need some costmap visualization messages in ROS.

fairlight1337 commented 10 years ago

Hey,

Gaya is right concerning the visualization via rviz. We found a multitude of good setups with which we can show what's going on, reasoning-wise. The probability-costmaps evolved to a somewhat good way to show what's going on, plus all the other stuff rviz can show. Concerning the interactive marker thing: Right, once this works nicely, triggering and parameterizing plans (at least stuff like pick up, put down) works via just clicking on the objects in rviz. So, I would prefer to keep the rvis costmap visualization :). Maybe a rework of the code (costmap-msgs) might still be a good idea.

moesenle commented 10 years ago

Collision maps were never optimal (ugly visualization, requiring an additional dependency, etc). However, they were the best fit. If I can remember correctly, the costmap 2d voxel grid visualization only allows for binary maps in 2 dimensions, i.e. voxels being either there or not (correct me if I'm wrong). That was not enough for my visualization requirements. When I started my OpenGL visualization, which is required anyway for visibility reasoning, I just implemented what I wanted to have there.

I agree that using rviz as the integrated visualization and control platform would be a good thing. But I also believe that neither VoxelGrid nor CollisionMap are the best choice here. I suggest to use markers. When I was implementing my visualization, there was no support for arbitrary 3d meshes, now there is as far as I can remember. It should be easy to reuse my code for tesselation of the location costfunctions to generate markers.

On Sun, Dec 15, 2013 at 4:34 PM, Jan Winkler notifications@github.comwrote:

Hey,

Gaya is right concerning the visualization via rviz. We found a multitude of good setups with which we can show what's going on, reasoning-wise. The probability-costmaps evolved to a somewhat good way to show what's going on, plus all the other stuff rviz can show. Concerning the interactive marker thing: Right, once this works nicely, triggering and parameterizing plans (at least stuff like pick up, put down) works via just clicking on the objects in rviz. So, I would prefer to keep the rvis costmap visualization :). Maybe a rework of the code (costmap-msgs) might still be a good idea.

— Reply to this email directly or view it on GitHubhttps://github.com/cram-code/cram_highlevel/issues/5#issuecomment-30609559 .