Skip to content
This repository has been archived by the owner on Nov 13, 2017. It is now read-only.

[reopen #274] Send Octomap diff instead of whole tree #302

Closed
wants to merge 5 commits into from

Conversation

130s
Copy link
Contributor

@130s 130s commented Jun 28, 2016

This enables Moveit to pass only the diff of the Octomap in a scene diff message when change detection is enabled on the Octree. This pull request depends on OctoMap/octomap#85 to compile. DO NOT MERGE until the Octomap pull request is accepted. moveit/moveit_ros#602 is the corresponding pull request in Moveit ROS for enabling change detection on the Octomap.

@dornhege I've rebased #274 to include updates (esp. CI config for testing). Thanks.

@130s
Copy link
Contributor Author

130s commented Jun 28, 2016

Comment from the original PR:

This is essentially #255 by @TheBrewCrew with some minor fixes.

The main reason is that in indigo we can only depend on OctoMap/octomap#103 and not OctoMap/octomap#85. This is handled in 28a6eb4. OctoMap/octomap#103 is already released as 1.6.9 in indigo (currently only shadow-fixed) and thus this can be merged once it is active.

I have left my additions as individual commits, so it is clear for reviewing this, what I changed.
I can also squash them in the original commits before merging, if someone gives me the go-ahead.

The corresponding pull request is moveit_ros is moveit/moveit_ros#636.

@dornhege
Copy link
Contributor

+1
I've tested this on the current indigo head in connection with moveit/moveit_ros#636 and it still works. I shouldn't merge this though as I did some of the changes on #274.

{
logInform("Cheaper to send tree instead of diff by %i bytes with %i changes", expected_size_diff-expected_size_tree, num_changes);
octomap_msgs::fullMapToMsg(*octree, scene_msg.world.octomap.octomap);
if(scene_msg.world.octomap.octomap.id != OCTOMAP_MSG_TYPE) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

curly brackets on new line

@davetcoleman
Copy link
Member

I wish we would all move away from deep changes like this in an LTS (indigo) release...

int expected_size_tree = octree->size()*(sizeof(float)+sizeof(char));
if (expected_size_diff > expected_size_tree)
{
logInform("Cheaper to send tree instead of diff by %i bytes with %i changes", expected_size_diff-expected_size_tree, num_changes);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this really be an inform? I would prefer debug.

@v4hn
Copy link
Contributor

v4hn commented Jul 21, 2016

I wish we would all move away from deep changes like this in an LTS (indigo) release...

Long-Term-Support means Stable API / Stable ABI. It does not mean "no new features".
As most people using MoveIt use indigo, it totally makes sense to add interesting features,
and also next year I don't see a reason not to consider merging new features in LTS branches.

@davetcoleman
Copy link
Member

I agree it does not mean no new features, but given our lack of good unit tests and integration tests its very risky we'll break current user's setups - for example it seems like this week's changes are causing problems. I'm fine making mistakes, but it should be in the right branch.

@v4hn
Copy link
Contributor

v4hn commented Jul 22, 2016

On Thu, Jul 21, 2016 at 01:18:03PM -0700, Dave Coleman wrote:

I agree it does not mean no new features, but given our lack of good unit tests and integration tests its very risky we'll break current user's setups for example it seems like this week's changes are causing problems.
I'm fine making mistakes, but it should be in the right branch.

I agree. But in my opinion neither indigo-devel, nor kinetic-devel are the right branch.
I would like to add this to next weeks agenda if we have time for it.

Btw: the message you referenced is not actually a problem of the indigo-devel branch.
Robert noticed an issue that was worse before, so this is still an improvement. :-)
I believe the biggest problem with the patch-set is moveit/moveit_ros#716 (comment) .

@davetcoleman
Copy link
Member

The right branch is technically the ROS-L branch ;-)

@v4hn
Copy link
Contributor

v4hn commented Jul 22, 2016

On Fri, Jul 22, 2016 at 11:58:18AM -0700, Dave Coleman wrote:

The right branch is technically the ROS-L branch ;-)

I would prefer a plain "master" branch.

@davetcoleman
Copy link
Member

it'd be great to get this merged in before friday's merge!

@dornhege
Copy link
Contributor

dornhege commented Aug 1, 2016

@130s : Do you want to address the proposed changes before the merge? Otherwise I can re-open a PR based on this one.

@130s
Copy link
Contributor Author

130s commented Aug 1, 2016

@dornhege thanks for the headsup and offering. Yes I appreciate if you could open a new PR.

@dornhege dornhege self-assigned this Aug 2, 2016
@dornhege
Copy link
Contributor

dornhege commented Aug 3, 2016

I can currently not test as moveit/moveit_ros#736 is preventing this from working. This might be resolved quickly, if it has something to do with my setup or is easily fixable.
I could test with ros-planning/moveit_ros#ae51d07d5b1b848d87acb8c7dacb078b17d9c5ca and still provide this PR cleaned, if someone feels confident with merging. These should be independent as one is in moveit_core and the other in moveit_ros.

@dornhege dornhege mentioned this pull request Aug 3, 2016
@dornhege
Copy link
Contributor

dornhege commented Aug 3, 2016

Continued in #322.

@dornhege dornhege closed this Aug 3, 2016
@130s 130s deleted the i/274_rebase branch August 3, 2016 17:36
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants