ipa320 / cob_navigation Goto Github PK

throws a lot of exceptions and warnings on the terminal

cob_linear_nav uses hardcoded robot specific tf frame in following locations.

https://github.com/ipa320/cob_navigation/blob/indigo_dev/cob_linear_nav/src/cob_linear_nav.cpp#L284

https://github.com/ipa320/cob_navigation/blob/indigo_dev/cob_linear_nav/src/cob_linear_nav.cpp#L293

This prevents from using this package in a multi robot environment. Following is my current tf tree. There could be multiples of such tree with different tf prefix (scout_1_tf, scout_2_tf etc) All ultimately connected by either static transform between /odom frames or through a parent map frame (world fixed). (On other hand why we need transforming odom vector to robot relative tf frame? Can't we just use raw value of odom without transforming?)

frames.pdf

Probably I might have setup all these in incorrect way or misunderstanding on how to use this package. But I believe if above two lines used a configurable value through rosparams I could get it to work. (Or robot_twist_linear_robot_ and robot_twist_angular_robot_ were simply assigned from odometry->twist.twist without any transform)

Thanks for your time

@ipa-mig
As already done for all cob_bringup packages

• fix/unify indentation in files
• replace std::cout with respective ROS_DEBUG/INFO/WARN/ERROR
• replace file headers with new ones, see https://github.com/ipa320/setup/tree/master/templates

pull request #17 (#17) broke the tests on jenkins, see http://cob-jenkins-server:8080/view/u_320/job/ipa320__prio_nongraphics_test/137/ due to the fact that it introduces a dependency to cob_driver/cob_sick_s300 which wasn't there before.

Adding this dependency doesn't make sense, so I'd like to move the code for the unified scan publisher to a new standalone package in cob_navigation.

Due to PR #66 some misconfigured costmap settings has been identified.
This will, however, be tackled in a seperate PR and should contain:

• Parameter map_type is outdated, needs to be removed. Is now configured in the plugins parameter via the ObstacleLayer or VoxelLayer. Maybe we need to change how/where this is configured...
• Adapt parameter for costmap scaling: inscribed_radius <= circumscribed_radius <= inflation_radius && cost_scaling_factor
• Check publish_voxel_map: this should only be true if we use a VoxelLayer
• Should we comment out the Voxel parameters if we don't use a VoxelLayer or configure them correctly for each robot?

@fmessmer FYI

Do we publish the obstacle information to the obstacle layer and the inflated obstacle layer during cob_navigation_slam? I saw the blue and red obstacles at http://wiki.ros.org/cob_tutorials/Tutorials/Navigation%20%28slam%29.

But I cannot see any of them with my robot - raw3-6. I tried to check rostopic info /move_base/local_costmap/obstacles and rostopic info /move_base/local_costmap/inflated_obstacles while I am doing https://github.com/ipa320/cob_navigation/blob/indigo_dev/cob_navigation_slam/launch/2dnav_ros_dwa.launch. But the publishers are None.

Does this have anything to do with

Thank you!

scan unifier produce gap on the back of cob4-2

@ipa-frm @ipa-mig

prerelease fails due to #18

Hello I did catkinisation and made some update of this repository. Please add hydro_dev branch so I can make pull-request so that other people can use it.

I just want to check again for an old problem which I have with tf2_ros::TransformListener but than couldn't find cob_unified_scan_publisher any more in cob_driver/cob_sick_s300 package. So i got confused when wasn't here also, but that's because it only added to groovy-dev, but not hydro-dev branch.

Can you please add it also into hydro-dev branch. Thanks!

cob_linear_nav uses hardcoded and tight velocity tolerances in detecting not moving due to obstacle.

https://github.com/ipa320/cob_navigation/blob/indigo_dev/cob_linear_nav/src/cob_linear_nav.cpp#L475

While it may not be intended for using outside cob family of robots, I have been successfully using this package as a generic package on different other robots. However above fixed and tight velocity tolerances causes problems where robot's odometer have inherent noise (e.g. Visual/Inertial only odometer)

I suggest setting above tolerance based on a ros param value (or two in case linear and angular thresholds need to be different) I'm glad to provide a PR if it is a welcome enhancement.