ipa320 / cob_robots Goto Github PK

As discussed #365 (comment)

running make test in cob_controller_configuration_gazebo fails. error see below.

checking ros/launch/default_controllers_cob3-5.launch
Traceback (most recent call last):
File "/opt/ros/groovy/share/roslaunch/scripts/roslaunch-check", line 85, in
error_msg = check_roslaunch_file(roslaunch_path)
File "/opt/ros/groovy/share/roslaunch/scripts/roslaunch-check", line 45, in check_roslaunch_file
error_msg = roslaunch.rlutil.check_roslaunch(roslaunch_file)
File "/opt/ros/groovy/lib/python2.7/dist-packages/roslaunch/rlutil.py", line 199, in check_roslaunch
base_pkg, file_deps, missing = roslaunch.depends.roslaunch_deps([f])
File "/opt/ros/groovy/lib/python2.7/dist-packages/roslaunch/depends.py", line 304, in roslaunch_deps
rl_file_deps(file_deps, launch_file, verbose)
File "/opt/ros/groovy/lib/python2.7/dist-packages/roslaunch/depends.py", line 212, in rl_file_deps
parse_launch(launch_file, file_deps, verbose)
File "/opt/ros/groovy/lib/python2.7/dist-packages/roslaunch/depends.py", line 197, in parse_launch
_parse_launch(launch_tag.childNodes, launch_file, file_deps, verbose, context)
File "/opt/ros/groovy/lib/python2.7/dist-packages/roslaunch/depends.py", line 135, in _parse_launch
v = _parse_arg(tag, context)
File "/opt/ros/groovy/lib/python2.7/dist-packages/roslaunch/depends.py", line 108, in _parse_arg
return (name, _get_arg_value(tag, context))
File "/opt/ros/groovy/lib/python2.7/dist-packages/roslaunch/depends.py", line 95, in _get_arg_value
raise RoslaunchDepsException("No value for arg [%s]"%(name))
roslaunch.depends.RoslaunchDepsException: No value for arg [robot]
make[4]: *** [CMakeFiles/roslaunch_check_ros_launch_default_controllers_cob3-5.launch_5] Error 1
make[4]: Target CMakeFiles/roslaunch_check_ros_launch_default_controllers_cob3-5.launch_5.dir/build' not remade because of errors. make[4]: Leaving directory/tmp/src/dry/cob_robots/cob_controller_configuration_gazebo/build'
make[3]: *** [CMakeFiles/roslaunch_check_ros_launch_default_controllers_cob3-5.launch_5.dir/all] Error 2
make[4]: Entering directory /tmp/src/dry/cob_robots/cob_controller_configuration_gazebo/build' make[4]: Leaving directory/tmp/src/dry/cob_robots/cob_controller_configuration_gazebo/build'
make[4]: Entering directory `/tmp/src/dry/cob_robots/cob_controller_configuration_gazebo/build'

after resetting the arm reference position with the Schunk MTS tool, we experience strange behaviour of the arm (not sure if it was there before too).

I sometimes can init, but then the modules show quick stop or emergency error. So it is impossible to move the arm. Recovering says "True" and in diagnostics you can very shortly see OK, but the quick stop or emergency stop is active again. see candump https://gist.github.com/ipa-fmw/d2355a5ad93af345ccf23b35637adb63

Most of the time I cannot init. Either it says:

robot@cob4-5-b1:~$ rosservice call /arm_right/driver/init
success: False
message: Internal limit active

or

robot@cob4-5-b1:~/git/setup_cob4/cob-pcs$ rosservice call /arm_right/driver/init
success: False
message: /u/robot/git/care-o-bot/src/ros_canopen/canopen_master/src/sdo.cpp(429): Throw in function void canopen::SDOClient::transmitAndWait(const canopen::ObjectDict::Entry&, const canopen::String&, canopen::String*)
Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<canopen::TimeoutException> >
std::exception::what: SDO
[canopen::tag_objectdict_key*] = 1a02sub0


robot@cob4-5-b1:~/git/setup_cob4/cob-pcs$ rosservice call /arm_right/driver/init
success: False
message: /u/robot/git/care-o-bot/src/ros_canopen/canopen_master/src/sdo.cpp(429): Throw in function void canopen::SDOClient::transmitAndWait(const canopen::ObjectDict::Entry&, const canopen::String&, canopen::String*)
Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<canopen::TimeoutException> >
std::exception::what: SDO
[canopen::tag_objectdict_key*] = 606bsub0

see candump https://gist.github.com/ipa-fmw/13ec36be17b7af4bebf7f9862bf394d3

arm config is:

rosparam get /arm_right/
arm_right_1_joint_position_controller: {joint: arm_right_1_joint, required_drive_mode: 1,
  type: position_controllers/JointPositionController}
arm_right_1_joint_velocity_controller: {joint: arm_right_1_joint, required_drive_mode: 2,
  type: velocity_controllers/JointVelocityController}
arm_right_2_joint_position_controller: {joint: arm_right_2_joint, required_drive_mode: 1,
  type: position_controllers/JointPositionController}
arm_right_2_joint_velocity_controller: {joint: arm_right_2_joint, required_drive_mode: 2,
  type: velocity_controllers/JointVelocityController}
arm_right_3_joint_position_controller: {joint: arm_right_3_joint, required_drive_mode: 1,
  type: position_controllers/JointPositionController}
arm_right_3_joint_velocity_controller: {joint: arm_right_3_joint, required_drive_mode: 2,
  type: velocity_controllers/JointVelocityController}
arm_right_4_joint_position_controller: {joint: arm_right_4_joint, required_drive_mode: 1,
  type: position_controllers/JointPositionController}
arm_right_4_joint_velocity_controller: {joint: arm_right_4_joint, required_drive_mode: 2,
  type: velocity_controllers/JointVelocityController}
arm_right_5_joint_position_controller: {joint: arm_right_5_joint, required_drive_mode: 1,
  type: position_controllers/JointPositionController}
arm_right_5_joint_velocity_controller: {joint: arm_right_5_joint, required_drive_mode: 2,
  type: velocity_controllers/JointVelocityController}
arm_right_6_joint_position_controller: {joint: arm_right_6_joint, required_drive_mode: 1,
  type: position_controllers/JointPositionController}
arm_right_6_joint_velocity_controller: {joint: arm_right_6_joint, required_drive_mode: 2,
  type: velocity_controllers/JointVelocityController}
arm_right_7_joint_position_controller: {joint: arm_right_7_joint, required_drive_mode: 1,
  type: position_controllers/JointPositionController}
arm_right_7_joint_velocity_controller: {joint: arm_right_7_joint, required_drive_mode: 2,
  type: velocity_controllers/JointVelocityController}
driver:
  bus: {device: can2}
  defaults:
    dcf_overlay: {604Csub1: '1', 604Csub2: '24000'}
    eds_file: common/Schunk_0_63.dcf
    eds_pkg: cob_hardware_config
    vel_to_device: rint(rad2deg(vel)*250)
  nodes:
  - {id: 51, name: arm_right_1_joint}
  - {id: 52, name: arm_right_2_joint}
  - {id: 53, name: arm_right_3_joint}
  - {id: 54, name: arm_right_4_joint}
  - {id: 55, name: arm_right_5_joint}
  - {id: 56, name: arm_right_6_joint}
  - {id: 57, name: arm_right_7_joint}
  sync: {interval_ms: 10, overflow: 0}
joint_group_position_controller:
  joints: [arm_right_1_joint, arm_right_2_joint, arm_right_3_joint, arm_right_4_joint,
    arm_right_5_joint, arm_right_6_joint, arm_right_7_joint]
  required_drive_mode: 1
  type: position_controllers/JointGroupPositionController
joint_group_velocity_controller:
  joints: [arm_right_1_joint, arm_right_2_joint, arm_right_3_joint, arm_right_4_joint,
    arm_right_5_joint, arm_right_6_joint, arm_right_7_joint]
  required_drive_mode: 2
  type: velocity_controllers/JointGroupVelocityController
joint_names: [arm_right_1_joint, arm_right_2_joint, arm_right_3_joint, arm_right_4_joint,
  arm_right_5_joint, arm_right_6_joint, arm_right_7_joint]
joint_state_controller: {publish_rate: 50, type: joint_state_controller/JointStateController}
joint_trajectory_controller:
  action_monitor_rate: 10
  constraints:
    arm_right_1_joint: {goal: 0.1, trajectory: 0.1}
    arm_right_2_joint: {goal: 0.1, trajectory: 0.1}
    arm_right_3_joint: {goal: 0.1, trajectory: 0.1}
    arm_right_4_joint: {goal: 0.1, trajectory: 0.1}
    arm_right_5_joint: {goal: 0.1, trajectory: 0.1}
    arm_right_6_joint: {goal: 0.1, trajectory: 0.1}
    arm_right_7_joint: {goal: 0.1, trajectory: 0.1}
    goal_time: 0.6
    stopped_velocity_tolerance: 0.05
  joints: [arm_right_1_joint, arm_right_2_joint, arm_right_3_joint, arm_right_4_joint,
    arm_right_5_joint, arm_right_6_joint, arm_right_7_joint]
  required_drive_mode: 7
  state_publish_rate: 25
  stop_trajectory_duration: 0.5
  type: position_controllers/JointTrajectoryController
max_command_silence: 0.5

diagnostics screenshot

We are still working with cob3-6. The robot is fully operational and with Indigo. We should keep its configuration.

currently returns

[INFO] [WallTime: 1447667136.528934] <<torso_front_home>> <<behavior>>
Unhandled exception in thread started by <rospy.impl.tcpros_service.ServiceProxy object at 0x7f1a7df0b3d0>
Traceback (most recent call last):
  File "/opt/ros/indigo/lib/python2.7/dist-packages/rospy/impl/tcpros_service.py", line 435, in __call__
    return self.call(*args, **kwds)
  File "/opt/ros/indigo/lib/python2.7/dist-packages/rospy/impl/tcpros_service.py", line 515, in call
    responses = transport.receive_once()
  File "/opt/ros/indigo/lib/python2.7/dist-packages/rospy/impl/tcpros_base.py", line 696, in receive_once
    p.read_messages(b, msg_queue, sock) 
  File "/opt/ros/indigo/lib/python2.7/dist-packages/rospy/impl/tcpros_service.py", line 353, in read_messages
    self._read_ok_byte(b, sock)
  File "/opt/ros/indigo/lib/python2.7/dist-packages/rospy/impl/tcpros_service.py", line 336, in _read_ok_byte
    raise ServiceException("service [%s] responded with an error: %s"%(self.resolved_name, str))
rospy.service.ServiceException: service [/behavior/torso_front_home] responded with an error: service cannot process request: service handler returned None

use for robotlist and envlist e.g. for install tags in various packages

See http://stackoverflow.com/questions/7787823/cmake-how-to-get-the-name-of-all-subdirectories-of-a-directory

as suggested by @ipa-mdl in #573 (comment)

Our new jenkins server reports build failures for the roslaunch tests in cob_hardware_test. Please use the tags in the tests (similar to the launch files in cob_bringup).

use "unset ROBOT" and "unset ROBOT_ENV" and then do a "make test" in cob_hardware_test to reproduce the error.

Speeds up init

This issue should be used to remember bringing PullRequests into Hydro that have only been tested for Groovy so far

@ipa-fmw
@ipa-nhg

The structure already got much simpler but there still is some potential.

I'm creating this issue for discussion following

• https://github.com/ipa320/cob_common/pull/175#issuecomment-154128294
• #359

This has minor priority for now...

@fmessmer FYI

It's currently not possible to find a clean structure for the launch and parameter files that set up all robots (cob3-6, cob3-9, cob4-1, cob4-2, cob4-6) in both real hardware and simulation with the new namespace layout under indigo!

We will need to review this

• after the new base controller plugins are finalized
• the cob3-X robots hardware is set up for indigo

@ipa-fmw @ipa-nhg @ipa-mig @ipa-mdl

We need to write these tests and add them to travis

@ipa-fmw @ipa-mdl
Do you have a good idea how to deal with the problem about using $(find ) and $(arg ) and such mixed together?

#300 introduced an include in raw3-3.xml which opens a dependency to rplidar_ros.

Although this is not used by default, the roslaunch check for cob_bringup fails now http://jenkins.ros.org/job/devel-indigo-cob_robots/ARCH_PARAM=amd64,UBUNTU_PARAM=trusty,label=devel/57/testReport/(root)/Results/test_ran/.
To avoid that we should add an empty package rplidar_ros to cob_substitute. @ipa-frm can you please add this and send a PR?

I have some tf problems (TF_OLD_DATA, etc.) and I think it is related to the change that every component has its own robot state publisher. Why do you think it is better to have so many (in my case 7) robot state publishers that are all publishing the same transforms?

When I run the tf_monitor i get this strange output with unknown publisher:

RESULTS: for all Frames

Frames:
Frame: /base_footprint published by unknown_publisher Average Delay: 0.185526 Max Delay: 0.18663
Frame: arm_0_link published by unknown_publisher Average Delay: -0.312836 Max Delay: 0
Frame: arm_1_link published by unknown_publisher Average Delay: 0.188703 Max Delay: 0.194755
Frame: arm_2_link published by unknown_publisher Average Delay: 0.188705 Max Delay: 0.194758
Frame: arm_3_link published by unknown_publisher Average Delay: 0.188706 Max Delay: 0.194759
Frame: arm_4_link published by unknown_publisher Average Delay: 0.188706 Max Delay: 0.19476
Frame: arm_5_link published by unknown_publisher Average Delay: 0.188707 Max Delay: 0.194761
Frame: arm_6_link published by unknown_publisher Average Delay: 0.188707 Max Delay: 0.194762
Frame: arm_7_link published by unknown_publisher Average Delay: 0.188708 Max Delay: 0.194763
Frame: base_laser_front_link published by unknown_publisher Average Delay: -0.312834 Max Delay: 0
Frame: base_laser_rear_link published by unknown_publisher Average Delay: -0.312833 Max Delay: 0
Frame: base_laser_top_link published by unknown_publisher Average Delay: -0.312832 Max Delay: 0
Frame: base_link published by unknown_publisher Average Delay: -0.312834 Max Delay: 0
Frame: bl_caster_r_wheel_link published by unknown_publisher Average Delay: 0.18574 Max Delay: 0.187387
Frame: bl_caster_rotation_link published by unknown_publisher Average Delay: 0.185742 Max Delay: 0.187388
Frame: br_caster_r_wheel_link published by unknown_publisher Average Delay: 0.185743 Max Delay: 0.187389
Frame: br_caster_rotation_link published by unknown_publisher Average Delay: 0.185743 Max Delay: 0.187389
Frame: cam3d_depth_frame published by unknown_publisher Average Delay: -0.312831 Max Delay: 0
Frame: cam3d_depth_optical_frame published by unknown_publisher Average Delay: -0.31283 Max Delay: 0
Frame: cam3d_link published by unknown_publisher Average Delay: -0.31283 Max Delay: 0
Frame: cam3d_rgb_frame published by unknown_publisher Average Delay: -0.312829 Max Delay: 0
Frame: cam3d_rgb_optical_frame published by unknown_publisher Average Delay: -0.312828 Max Delay: 0
Frame: fl_caster_r_wheel_link published by unknown_publisher Average Delay: 0.185744 Max Delay: 0.18739
Frame: fl_caster_rotation_link published by unknown_publisher Average Delay: 0.185745 Max Delay: 0.187391
Frame: fr_caster_r_wheel_link published by unknown_publisher Average Delay: 0.185746 Max Delay: 0.187391
Frame: fr_caster_rotation_link published by unknown_publisher Average Delay: 0.185746 Max Delay: 0.187392
Frame: head_axis_link published by unknown_publisher Average Delay: 0.185114 Max Delay: 0.185585
Frame: head_base_link published by unknown_publisher Average Delay: -0.312828 Max Delay: 0
Frame: head_cam_reference_link published by unknown_publisher Average Delay: -0.312827 Max Delay: 0
Frame: head_cover_link published by unknown_publisher Average Delay: -0.312826 Max Delay: 0
Frame: lookat_base_link published by unknown_publisher Average Delay: -0.312825 Max Delay: 0
Frame: pg70_finger_left_link published by unknown_publisher Average Delay: 0.18832 Max Delay: 0.188673
Frame: pg70_finger_right_link published by unknown_publisher Average Delay: 0.188322 Max Delay: 0.188675
Frame: pg70_gripper_link published by unknown_publisher Average Delay: -0.312824 Max Delay: 0
Frame: torso_base_link published by unknown_publisher Average Delay: -0.312824 Max Delay: 0
Frame: torso_lower_neck_tilt_link published by unknown_publisher Average Delay: 0.188553 Max Delay: 0.189466
Frame: torso_pan_link published by unknown_publisher Average Delay: 0.188555 Max Delay: 0.189468
Frame: torso_upper_neck_tilt_link published by unknown_publisher Average Delay: 0.188556 Max Delay: 0.18947
Frame: tray_base_link published by unknown_publisher Average Delay: -0.312823 Max Delay: 0
Frame: tray_left_link published by unknown_publisher Average Delay: -0.312822 Max Delay: 0
Frame: tray_link published by unknown_publisher Average Delay: 0.188313 Max Delay: 0.188757
Frame: tray_phidgets_1_link published by unknown_publisher Average Delay: -0.312821 Max Delay: 0
Frame: tray_phidgets_2_link published by unknown_publisher Average Delay: -0.312821 Max Delay: 0
Frame: tray_phidgets_3_link published by unknown_publisher Average Delay: -0.31282 Max Delay: 0
Frame: tray_phidgets_4_link published by unknown_publisher Average Delay: -0.312819 Max Delay: 0
Frame: tray_right_link published by unknown_publisher Average Delay: -0.312819 Max Delay: 0

All Broadcasters:
Node: unknown_publisher 571.44 Hz, Average Delay: -0.0757929 Max Delay: 0.19476

And roswtf:

ERROR TF multiple authority contention:

• node [/tray/robot_state_publisher] publishing transform [arm_0_link] with parent [base_link] already published by node [/torso/robot_state_publisher]
• node [/tray/robot_state_publisher] publishing transform [base_link] with parent [base_footprint] already published by node [/torso/robot_state_publisher]
• node [/tray/robot_state_publisher] publishing transform [base_laser_front_link] with parent [base_link] already published by node [/torso/robot_state_publisher]
• node [/tray/robot_state_publisher] publishing transform [base_laser_rear_link] with parent [base_link] already published by node [/torso/robot_state_publisher]
• node [/tray/robot_state_publisher] publishing transform [base_laser_top_link] with parent [base_link] already published by node [/torso/robot_state_publisher]
• node [/tray/robot_state_publisher] publishing transform [cam3d_depth_frame] with parent [cam3d_link] already published by node [/torso/robot_state_publisher]
• node [/tray/robot_state_publisher] publishing transform [cam3d_depth_optical_frame] with parent [cam3d_depth_frame] already published by node [/torso/robot_state_publisher]

and so on...

After init the axis the service returns a success and if I try to init again the component answer that the component is already initialized, I can read the joint_states but I can't move it (the controllers are not properly loaded).

Canopen RELEASE version

INIT:

[ INFO] [1479722779.349713591]: Initializing XXX
[ INFO] [1479722779.357355224]: Current state: 1 device error: system:0 internal_error: 0 (OK)
[ INFO] [1479722779.357563119]: Current state: 2 device error: system:0 internal_error: 0 (OK)
[ERROR] [1479722780.938229190]: Node has emergency error
illegal tranistion 2 -> 4
Could not switch to mode 7, reason: Could not set transition
[ERROR] [1479722781.568261371]: head_2_jointcould not enter mode 7
illegal tranistion 2 -> 4
Could not switch to mode 7, reason: Could not set transition
[ERROR] [1479722781.568315266]: head_3_jointcould not enter mode 7

RECOVER:

[ INFO] [1479722806.798563675]: Recovering XXX
illegal tranistion 8 -> 6
[ERROR] [1479722810.948258587]: Node has emergency error

Canopen actual upstream version

INIT:

[ INFO] [1479723804.924223296]: Using fixed control period: 0.010000000
[ INFO] [1479723811.784164858]: Initializing XXX
[ INFO] [1479723811.784535908]: Current state: 1 device error: system:0 internal_error: 0 (OK)
[ INFO] [1479723811.784744277]: Current state: 2 device error: system:0 internal_error: 0 (OK)
[ERROR] [1479723812.085581742]: Node has emergency error
[ERROR] [1479723814.196398293]: head_2_joint is not ready to switch mode
[ERROR] [1479723814.196489782]: Could not switch controllers. The hardware interface combination for the requested controllers is unfeasible.

RECOVER:

[ INFO] [1479723840.030840279]: Recovering XXX
illegal tranistion 8 -> 6
[ERROR] [1479723842.105543416]: Node has emergency error

@ipa-mdl do you have any idea where could be the problem?

as done in ipa320/schunk_modular_robotics#171

as documented in xacro

affects:

• xacro:include
• xacro:property
• xacro:insert_block
• xacro:arg
• xacro:if/xacro:unless

apply these changes to all xacro-files (cob_calibration_data, cob_common, cob_robots,....etc.)

Use the helper command

find . -iname "*.xacro" | xargs sed -i 's#<\([/]\?\)\(if\|unless\|include\|arg\|property\|macro\|insert_block\)#<\1xacro:\2#g'

add the configuration files to https://github.com/ipa320/cob_calibration_data/tree/indigo_dev/cob4-1/calibration/cameras

currently done and tested for cob4-2 (see #405).
Instructions see #405 (comment)

@destogl will test with raw3-5

currently can0.yaml is used on the base pc for the base and on the torso pc for the arms/sensorring/torso. If we keep a common can0.yaml we cannot have different CAN configurations for e.g. base and torso.

@ipa-mdl had some suggestion how to restructure

@ipa-nhg @ipa-fmw

This is evolving from #459 (comment)

Beside the discussion about what to do about env.sh, the following things need to be done (@ipa-nhg)

• accounts need to be generated for all users that have an account on the base-pc
• perform ssh-copy-id and make sure there is a valid .bashrc (cob_default.bashrc is fine) that is sourced

Sorry if this isn't the right forum for this. I'm curious as to how the architecture of your gripper control looks like? Is it multi-dof? What plugins do you use for gazebo?

I'm trying to make the 3 finger roboteq s-model claw work in gazebo, but need a controller for it. Did you guys manage to make a multi-dof thing work with the jointtrajectory effort controller?

@ipa-fmw , @ipa-nhg . Please be aware that the canopen executable name has changed in Hydro to ipa_canopen_ros instead of canopen_ros. This was the cause of the issue in cob3-3.

especially for torso movements and pick movements, we should check every command using the handles and abort if a previous movement cannot be completed as expected!

handle = sss.move()
handle.wait()
if handle.get_error_code() != 0:
   ABORT

• define a handle for each sss.move command
• wait for movements to be finished before executing new movements
• do NOT use spleep() to synchronize movements (which can cause a collission)
• only continue if error_code is zero (==0)

This is currently missing for pick! ...disabling this button for now in the robot dashboard!

in raw3-1.xml the relayboard.launch is started in simulation mode which results in a wrong ns of the /emergency_stop_state topic (which is relayboard/emergency_stop_state) and the robot can not be moved.

https://github.com/ipa320/cob_driver/pull/148 introduced new parameters

• max_trans_velocity
• max_rot_velocity

Currently they are not set within any yaml file, thus the hasParam-check fails and the default value is used. It would be good to know in which yaml these parameters can be set (in cob_hardware_config?). There should be a respective entry in the according yaml for all robots (using the same default value as in the code)
--> reduces output when starting bringup/bringup_sim

@ipa-frm

The "cob_bringup" package has a dependency to the package "ur_driver". I found the following repositories:

• https://github.com/ipa-nhg/ur_driver: here it seems that ur_driver would be a stack, but there is only one package inside (ur_description).
• https://kforge.ros.org/ros_industrial/universal_robot and https://github.com/ros-industrial/universal_robot: here there are only "ur5_*" packages. But in "./cob_bringup/components/ur10.launch" and "./cob_bringup/manifest.xml" it is refered to the "ur_driver" package

So it seems that it is mixed up.

after apt-get installing cob_simulation and starting with roslauch cob_bringup_sim robot.launch the following error occurs:
ERROR: cannot launch node of type [cob_controller_configuration_gazebo/gazebo_services.py]: can't locate node [gazebo_services.py] in package [cob_controller_configuration_gazebo]

Tried to start the node with rosrun cob_controller_configuration_gazebo gazebo_services.py, which leads to the following error:
[rosrun] Couldn't find executable named gazebo_services.py below opt/ros/indigo/share/cob_controller_configuration_gazebo

ros seems to look for the executable in /opt/ros/indigo/share/cob_controller_configuration_gazebo but it is actually located under /opt/ros/indigo/lib/cob_controller_configuration_gazebo/src

from travis (Parameters [has_podest] were not set for macro xacro:schunk_pg70):

  /usr/bin/cmake -E make_directory /home/travis/catkin_ws/build/test_results/cob_bringup

  /opt/ros/indigo/share/roslaunch/cmake/../scripts/roslaunch-check -o /home/travis/catkin_ws/build/test_results/cob_bringup/roslaunch-check_cob3-9__ROBOT_ENV_ipa-factory.xml.xml /home/travis/catkin_ws/src/cob_robots/cob_bringup/robots/cob3-9.xml ROBOT_ENV=ipa-factory

checking /home/travis/catkin_ws/src/cob_robots/cob_bringup/robots/cob3-9.xml

Traceback (most recent call last):

  File "/opt/ros/indigo/share/xacro/xacro.py", line 62, in <module>

    xacro.main()

  File "/opt/ros/indigo/lib/python2.7/dist-packages/xacro/__init__.py", line 696, in main

    eval_self_contained(doc)

  File "/opt/ros/indigo/lib/python2.7/dist-packages/xacro/__init__.py", line 626, in eval_self_contained

    eval_all(doc.documentElement, macros, symbols)

  File "/opt/ros/indigo/lib/python2.7/dist-packages/xacro/__init__.py", line 552, in eval_all

    (",".join(params), str(node.tagName)))

xacro.XacroException: Parameters [has_podest] were not set for macro xacro:schunk_pg70

...writing test results to /home/travis/catkin_ws/build/test_results/cob_bringup/roslaunch-check_cob3-9__ROBOT_ENV_ipa-factory.xml.xml

FAILURE:

[/home/travis/catkin_ws/src/cob_robots/cob_bringup/robots/cob3-9.xml]:

	while processing /home/travis/catkin_ws/src/cob_robots/cob_hardware_config/common/upload_robot.launch:

Invalid <param> tag: Cannot load command parameter [robot_description]: command [/opt/ros/indigo/share/xacro/xacro.py '/home/travis/catkin_ws/src/cob_robots/cob_hardware_config/cob3-9/urdf/cob3-9.urdf.xacro'] returned with code [1]. 

While hunting for bugs, deprecation warnings and other things in indigo_dev, I found that with our current parameter layout in the local_costmap_params.yaml files we have the same issue as reported here:
http://answers.ros.org/question/83031/move_base-and-costmap_layers/

There is a response to the thread which explains what should be done.
The issue is also documented on the hydro migration guide:
http://wiki.ros.org/hydro/Migration#Navigation_-_Costmap2D

As I'm not working with navigation, I'm not sure whether the deprecation warning

[ INFO] [1413985288.872836730, 3.882000000]: Loading from pre-hydro parameter style
[ INFO] [1413985288.946924195, 3.918000000]: Using plugin "obstacle_layer"
[ INFO] [1413985289.094331450, 3.957000000]:     Subscribed to Topics: laser_scan_sensor_front laser_scan_sensor_rear

already results in false behaviour or not.

However, I wanted to document it!
@abubeck @ipa-mig @ipa-frm @ipa-srd @ipa-flg

see https://github.com/ipa320/cob4/issues/179

The controller_manager spawner script does not really suit our use case with deferred initialization.
As mentioned in ros-controls/ros_control#188 we should just use the controller_manager script.
The spawner is meant for on-demand start of controllers via launch files with life cycle management.

So we can achieve the desired behaviour with:

<node ns="$(arg component)" name="$(arg component)_controller_spawner" pkg="controller_manager" type="controller_manager" args="spawn joint_state_controller joint_trajectory_controller" respawn="false" output="screen" />

This node just waits (indefinitely) for the controller manager services, calls load and start for the list of controllers, and exits.

for new structure:
action_name: /arm_left/joint_trajectory_controller/follow_joint_trajectory
service_ns: /arm_left/driver

for old structure
action_name: /arm_left_controller/follow_joint_trajectory
service_ns: /arm_left_controller

The controller parameters for the following components have not been optimized yet:

• cob3_torso_v1
• schunk_lwa
• cob3_tray_3DOF
• ur_connector
• cob4_torso
• cob4_head
• cob4_sensorring
• ...

according to #414 (comment), we do not need parameters for modules which does not exists on the robot in the teleop.yaml.

So all parameters X_button can be removed in case component X is not part of the robot.

I tried to initialize platform with joystick when emergency stop button was active and even there is an error in communication with motors there is ROS-INFO output about success of initialization.

see comments in #541 (review)

taken from #347:
cam3d topic names need a significant review anyway as topics in simulation do not match the topic names on real hardware for most of the kinect/softkinetic/prosilica sensors....

As #346 tries to introduce a consistent naming in simulation...can we tackle this issue after #346 has been merged and then try to remove trailing slashes for link_names wherever it applies?

If we move the data out of the driver.yaml, we can reuse the same driver config for all cob4 bases.
The param upload can be done in a single place after #575 was merged.

@fmessmer FYI

there's no robot which uses softkinetic anymore, so we can get rid of the dependency.

See discussion started here

There are wrong reference values for arm_6_joint in all cob3's with schunk arm (cob3-2, cob3-5, cob3-6)!
They are way too large and lead to controller error (>0.15)

Query the correct values from the respective robot hardware!

• single robot_state_publisher with joint_state_publisher which aggregates joint_states
• fixed sdhx driver (joint orientation, see robot user on cob4-2)

there should be one launch file after ipa320/cob_android#5 is done

@fmessmer FYI