4am-robotics / cob_common Goto Github PK

related to

• ipa320/cob_simulation#150
• ipa320/schunk_modular_robotics#189

[ WARN] [1499671498.320796292, 0.162000000]: Deprecated syntax, please prepend 'hardware_interface/' to 'PositionJointInterface' within the <hardwareInterface> tag in joint 'XXX'.

needs to be adjusted in the joint's transmissions e.g. https://github.com/ipa320/cob_common/blob/indigo_dev/cob_description/urdf/common.xacro#L85-L97

However, this is currently not dual-distro compatible with indigo

@fmessmer FYI

After next release of ros_comm_msgs, cob_srvs::Trigger is replaced by std_srvs::Trigger service....restructure all packages accordingly and remove cob_srvs::Trigger service

Also cleanup deprecated services, e.g. SetOperationMode....i.e. use SetString instead!

see https://github.com/ipa320/cob_common/pull/240#issuecomment-342476604

@ipa-rmb @ipa-fmw @mgruhler please fix

arm_ prefix is hard-coded

@ipa-fxm

cob_description/urdf/ur_arm/ur5_arm.urdf.xacro

    <joint name="${name}_base_joint" type="fixed" >
      <insert_block name="origin" />
      <parent link="${parent}" />
      <child link="${name}_base_link" />
    </joint>

    <!-- include universal_robot arm -->
    <xacro:ur5_robot prefix="${name}_"/>

cob_description/urdf/ur_arm/ur10_arm.urdf.xacro

    <joint name="${name}_base_joint" type="fixed" >
      <insert_block name="origin" />
      <parent link="${parent}" />
      <child link="${name}_base_link" />
    </joint>

    <!-- include universal_robot arm -->
    <xacro:ur10_robot prefix="${name}_"/>

as mentioned and observed by @ipa-pfs both cob and raw are spinning when simulated in gazebo although no command is sent, i.e .they start spinning right after being spawned

this seems to be a physics (inertia, friction) problem of the base, most likely the drive_wheel model, as it can be observed that:

• no command is sent by cob_omni_drive_controller
• wheels are not oriented towards the observed motion
• not all wheels are rotating/moving (check frames in rviz and gazebo in wireframe view)

currently used: 0.08m radius (=0.16m diameter)
correct is: 0.0782 radius (=0.1564m diameter)

defined in https://github.com/ipa320/cob_common/blob/indigo_dev/cob_description/urdf/cob4_base/base.urdf.xacro#L12

On raw3-5 commit dc9b054 breaks orientation of laser scanners so that the data from laser-scanner are wrongly rotated.

Why did you do this changes, because they are just wrong, at least for raw3-5?

Thanks and regards,

Denis

On the robot the realsense driver define the tf tree of the camera links (for example rgb_optical_frame) and the urdf file contains only the camera_link.

On the other hand, the simulation ( the libgazebo_ros_openni_kinect plugin) requires an urdf where all the links are defined.

From my point of view we have 2 options:

• Define 2 separate URDF files for realsense, one for real robot and one for simulation.
• Create a new libgazebo plugin for realsense.

openning this issue as a follow up of #233
related is #219

the currently used gazebo_plugin_libraries, i.e. libgazebo_ros_depth_camera.so for sick_3dcs and libgazebo_ros_camera.so for head_usb_cam, do not properly reflect the characteristics of the real hardware and the respective drivers:

• the plugins currently used, e.g. publish additional topics or are lacking of publishing some topics
• the current camera properties might not be correct, i.e. field of view, resolution, update_rate, color_encoding,...
• the head_usb_cam does not properly support the fisheye optics, i.e. 170° fov
• ...

in order to properly simulate these sensors most likely custom libraries need to be implemented...
@ipa-rmb @ipa-nhg @cagbal @fmessmer FYI

As we are experiencing severe issues when trying to do distance computation (for cob_obstacle_distance or in obstacle_distance) with link geometries represented by geometric primitives (box, cylinder, sphere), I think it would be helpful to replace all those link geometries by according meshes. This mainly involve all the dummy links (such as the "component_base_links").

To simplify the process, we have started to prepare suitable macros in my branch. This approach has already been used by @ipa-mdl within another project successfully where it solved known issues related to MoveIt! which also uses fcl.

Related fcl issues: in particular flexible-collision-library/fcl#76

@fmessmer FYI

Can we please get a bloom release to jazzy and rolling? Specifically, releasing to rolling will save you from me nagging about releases in the future as new releases will always branch of rolling and therefore automatically will have a bloom release for any future ROS distribution.

Are there plans to release this via bloom for humble to the Debian repo?

Find a urdf structure to define the posible torso and head options (fixed or revolute joints).

*A diferent urdf file pro option?
*Using property blocks ?

On the real robot we have the following topics:

/sensorring_cam3d_front/depth/camera_info
/sensorring_cam3d_front/depth/image
/sensorring_cam3d_front/depth/image/compressed
/sensorring_cam3d_front/depth/image/compressed/parameter_descriptions
/sensorring_cam3d_front/depth/image/compressed/parameter_updates
/sensorring_cam3d_front/depth/image/compressedDepth
/sensorring_cam3d_front/depth/image/compressedDepth/parameter_descriptions
/sensorring_cam3d_front/depth/image/compressedDepth/parameter_updates
/sensorring_cam3d_front/depth/image/theora
/sensorring_cam3d_front/depth/image/theora/parameter_descriptions
/sensorring_cam3d_front/depth/image/theora/parameter_updates
/sensorring_cam3d_front/depth/image_rect
/sensorring_cam3d_front/depth/image_rect/compressed
/sensorring_cam3d_front/depth/image_rect/compressed/parameter_descriptions
/sensorring_cam3d_front/depth/image_rect/compressed/parameter_updates
/sensorring_cam3d_front/depth/image_rect/compressedDepth
/sensorring_cam3d_front/depth/image_rect/compressedDepth/parameter_descriptions
/sensorring_cam3d_front/depth/image_rect/compressedDepth/parameter_updates
/sensorring_cam3d_front/depth/image_rect/theora
/sensorring_cam3d_front/depth/image_rect/theora/parameter_descriptions
/sensorring_cam3d_front/depth/image_rect/theora/parameter_updates
/sensorring_cam3d_front/depth/intensity
/sensorring_cam3d_front/depth/intensity/compressed
/sensorring_cam3d_front/depth/intensity/compressed/parameter_descriptions
/sensorring_cam3d_front/depth/intensity/compressed/parameter_updates
/sensorring_cam3d_front/depth/intensity/compressedDepth
/sensorring_cam3d_front/depth/intensity/compressedDepth/parameter_descriptions
/sensorring_cam3d_front/depth/intensity/compressedDepth/parameter_updates
/sensorring_cam3d_front/depth/intensity/theora
/sensorring_cam3d_front/depth/intensity/theora/parameter_descriptions
/sensorring_cam3d_front/depth/intensity/theora/parameter_updates
/sensorring_cam3d_front/depth/ios
/sensorring_cam3d_front/depth/points

The visuals and the collision model does not seems to fit to the usb_cam cob4 is using in the head.
see here: https://github.com/ipa320/cob_common/blob/kinetic_dev/cob_description/urdf/sensors/usb_cam.urdf.xacro

see https://github.com/ipa320/cob_common/pull/139#discussion_r24563453

@fmessmer FYI

@ipa-fxm: Remove strange physics values in base.gazebo.xacro for cob_wheels

Hey,
I wondered whether you are using a defined code style (for C++), and which one it is. Have you chosen a common one or do you have internal guidelines/formatting files?
I am planning to contribute back and am currently reformatting the changes to have less PR diff. Your code style (in the Schunk SDH package for example) seems to be similar to the ROS formatting, with public blocks indented (cf. http://wiki.ros.org/IDEs#Auto_Formatting), no deletion of trailing white spaces, and no one-space indentation of comment blocks. Is this correct?

Thanks,
Wolfgang

check with latest sdhx driver

urdfdom is not a valid dependency anymore: https://github.com/ipa320/cob_common/blob/dfb91fb709e997d0b2882677127cc10288acb165/cob_description/package.xml#L23

See ros/rosdistro#4633

@srd-tk found that the gazebo tags for some of the sensors in cob_common are outdated.

@srd-tk can you please send a PullRequest with your solution?

• provide proper separate wheel-xacro for the IPA Fahrdrehmodul (replacing ancient PR2-wheel)
• provide means to be able to set calibration/mount properties for attached laser scanner
• remove unsupported calibration_rising tags and *ref-properties

Hi,
it looks like your web page link is not your landing page anymore !?

Could you please release this for Noetic? (at least cob_msgs, needed by cob_undercarriage_ctrl)

@ipa-nhg @ipa-tif
Please verify the kinematic description (URDF) of cob4_head (static and 3dof).
I think the origins for the joints are incorrect (maybe only wrong signs).

In the current version head_center_link is not translational invariant (it does translate when moving the joints).

@ipa-bnm