0
$\begingroup$

Rosanswers logo

I am programming with the Fetch robot (the physical one, not Gazebo simulation).

I use my laptop with the following settings:

  • Macbook Pro Late 2013 edition
  • Ubuntu 14.04 installed as sole operating system
  • ROS Indigo
  • Plus the Fetch ROS from here.

Also the ROS variables:

<fetch>~/FETCH_CORE/fetch_core$ env | grep ROS
ROS_ROOT=/opt/ros/indigo/share/ros
ROS_PACKAGE_PATH=/opt/ros/indigo/share:/opt/ros/indigo/stacks
ROS_MASTER_URI=http://fetch59.local:11311
ROSLISP_PACKAGE_DIRECTORIES=
ROS_DISTRO=indigo
ROS_IP=10.0.0.121
ROS_HOME=/home/daniel/.ros
ROS_ETC_DIR=/opt/ros/indigo/etc/ros

I have the following ROS topics:

<fetch>~/FETCH_CORE/fetch_core$ rostopic list
/arm_controller/cartesian_twist/command
/arm_controller/follow_joint_trajectory/cancel
/arm_controller/follow_joint_trajectory/feedback
/arm_controller/follow_joint_trajectory/goal
/arm_controller/follow_joint_trajectory/result
/arm_controller/follow_joint_trajectory/status
/arm_with_torso_controller/follow_joint_trajectory/cancel
/arm_with_torso_controller/follow_joint_trajectory/feedback
/arm_with_torso_controller/follow_joint_trajectory/goal
/arm_with_torso_controller/follow_joint_trajectory/result
/arm_with_torso_controller/follow_joint_trajectory/status
/base_controller/command
/base_scan
/base_scan_no_self_filter
/base_scan_raw
/base_scan_tagged
/battery_state
/charge_lockout/cancel
/charge_lockout/feedback
/charge_lockout/goal
/charge_lockout/result
/charge_lockout/status
/cmd_vel
/cmd_vel_mux/selected
/diagnostics
/diagnostics_agg
/diagnostics_toplevel_state
/dock/result
/enable_software_runstop
/graft/state
/gripper/gyro_offset
/gripper/imu
/gripper/imu_raw
/gripper_controller/gripper_action/cancel
/gripper_controller/gripper_action/feedback
/gripper_controller/gripper_action/goal
/gripper_controller/gripper_action/result
/gripper_controller/gripper_action/status
/gripper_controller/led_action/cancel
/gripper_controller/led_action/feedback
/gripper_controller/led_action/goal
/gripper_controller/led_action/result
/gripper_controller/led_action/status
/gripper_state
/head_camera/crop_decimate/parameter_descriptions
/head_camera/crop_decimate/parameter_updates
/head_camera/depth/camera_info
/head_camera/depth/image
/head_camera/depth/image_raw
/head_camera/depth/image_rect
/head_camera/depth/image_rect_raw
/head_camera/depth/points
/head_camera/depth_downsample/camera_info
/head_camera/depth_downsample/image_raw
/head_camera/depth_downsample/points
/head_camera/depth_rectify_depth/parameter_descriptions
/head_camera/depth_rectify_depth/parameter_updates
/head_camera/depth_registered/camera_info
/head_camera/depth_registered/hw_registered/image_rect
/head_camera/depth_registered/hw_registered/image_rect_raw
/head_camera/depth_registered/image
/head_camera/depth_registered/image_raw
/head_camera/depth_registered/points
/head_camera/depth_registered_rectify_depth/parameter_descriptions
/head_camera/depth_registered_rectify_depth/parameter_updates
/head_camera/driver/parameter_descriptions
/head_camera/driver/parameter_updates
/head_camera/head_camera_nodelet_manager/bond
/head_camera/ir/camera_info
/head_camera/ir/image
/head_camera/projector/camera_info
/head_camera/rgb/camera_info
/head_camera/rgb/image_raw
/head_camera/rgb/image_rect_color
/head_camera/rgb_rectify_color/parameter_descriptions
/head_camera/rgb_rectify_color/parameter_updates
/head_controller/follow_joint_trajectory/cancel
/head_controller/follow_joint_trajectory/feedback
/head_controller/follow_joint_trajectory/goal
/head_controller/follow_joint_trajectory/result
/head_controller/follow_joint_trajectory/status
/head_controller/point_head/cancel
/head_controller/point_head/feedback
/head_controller/point_head/goal
/head_controller/point_head/result
/head_controller/point_head/status
/imu
/imu1/gyro_offset
/imu1/imu
/imu1/imu_raw
/imu2/gyro_offset
/imu2/imu
/imu2/imu_raw
/joint_states
/joy
/laser_self_filter/cancel
/laser_self_filter/feedback
/laser_self_filter/goal
/laser_self_filter/result
/laser_self_filter/status
/odom
/odom_combined
/query_controller_states/cancel
/query_controller_states/feedback
/query_controller_states/goal
/query_controller_states/result
/query_controller_states/status
/robot_state
/robotsound
/rosout
/rosout_agg
/sick_tim551_2050001/parameter_descriptions
/sick_tim551_2050001/parameter_updates
/software_runstop_enabled
/sound_play/cancel
/sound_play/feedback
/sound_play/goal
/sound_play/result
/sound_play/status
/teleop/cmd_vel
/tf
/tf_static
/torso_controller/follow_joint_trajectory/cancel
/torso_controller/follow_joint_trajectory/feedback
/torso_controller/follow_joint_trajectory/goal
/torso_controller/follow_joint_trajectory/result
/torso_controller/follow_joint_trajectory/status

So far so good. Now I want to check the joint angles. What I often do here is echo the corresponding ROS topic. Here I call rostopic echo -n 1 /joint_states repeatedly. I press ENTER on my keyboard, then I count 4-5 seconds in my head, then press ENTER again, then count 4-5 seconds, press ENTER again, and so forth. Check out the output after running this several times:

<fetch>~/FETCH_CORE/fetch_core$ rostopic echo -n 1 /joint_states
header: 
  seq: 63846
  stamp: 
    secs: 1526495986
    nsecs: 155393416
  frame_id: ''
name: ['l_gripper_finger_joint', 'r_gripper_finger_joint']
position: [0.004585660994052887, 0.004585660994052887]
velocity: [-4.410743713378906e-06, -4.410743713378906e-06]
effort: [0.0, 0.0]
---
<fetch>~/FETCH_CORE/fetch_core$ rostopic echo -n 1 /joint_states
header: 
  seq: 64562
  stamp: 
    secs: 1526495993
    nsecs: 315394732
  frame_id: ''
name: ['l_gripper_finger_joint', 'r_gripper_finger_joint']
position: [0.004585575312376022, 0.004585575312376022]
velocity: [-0.0, -0.0]
effort: [0.0, 0.0]
---
<fetch>~/FETCH_CORE/fetch_core$ rostopic echo -n 1 /joint_states
header: 
  seq: 65164
  stamp: 
    secs: 1526495999
    nsecs: 335393351
  frame_id: ''
name: ['l_gripper_finger_joint', 'r_gripper_finger_joint']
position: [0.004585616290569305, 0.004585616290569305]
velocity: [-2.086162567138672e-06, -2.086162567138672e-06]
effort: [0.0, 0.0]
---
<fetch>~/FETCH_CORE/fetch_core$ rostopic echo -n 1 /joint_states
header: 
  seq: 65728
  stamp: 
    secs: 1526496004
    nsecs: 975435878
  frame_id: ''
name: ['l_gripper_finger_joint', 'r_gripper_finger_joint']
position: [0.004585575312376022, 0.004585575312376022]
velocity: [1.1920928955078125e-07, 1.1920928955078125e-07]
effort: [0.0, 0.0]
---
<fetch>~/FETCH_CORE/fetch_core$ rostopic echo -n 1 /joint_states
header: 
  seq: 66307
  stamp: 
    secs: 1526496010
    nsecs: 765425292
  frame_id: ''
name: ['l_gripper_finger_joint', 'r_gripper_finger_joint']
position: [0.004585538059473038, 0.004585538059473038]
velocity: [2.4437904357910156e-06, 2.4437904357910156e-06]
effort: [0.0, 0.0]
---
<fetch>~/FETCH_CORE/fetch_core$ rostopic echo -n 1 /joint_states
header: 
  seq: 66830
  stamp: 
    secs: 1526496016
    nsecs: 477241490
  frame_id: ''
name: ['l_wheel_joint', 'r_wheel_joint', 'torso_lift_joint', 'bellows_joint', 'head_pan_joint', 'head_tilt_joint', 'shoulder_pan_joint', 'shoulder_lift_joint', 'upperarm_roll_joint', 'elbow_flex_joint', 'forearm_roll_joint', 'wrist_flex_joint', 'wrist_roll_joint']
position: [-6.072175025939941, -0.20786872506141663, 0.002922113984823227, 0.0, 0.008403897285461426, 0.4989619489959717, 1.3218759175231933, 1.4561462151916504, -0.19919875611728668, 0.6284374523010254, 0.0005699233077907564, 2.0629285788806153, -0.00028681149895191244]
velocity: [-1.1920928955078125e-07, 0.0, -3.5762786865234375e-07, -1.7881393432617188e-07, -2.5451183319091797e-05, -0.0003771781921386719, 0.0003428459167480469, -0.0002372264862060547, 0.00010061264038085938, 0.00023758411407470703, 0.000217437744140625, -0.00033020973205566406, -4.589557647705078e-05]
effort: [-0.0, 0.0, 0.0, 0.0, -0.0, -0.0, -0.0, -0.0, -0.0, -0.0, -0.0, -0.0, -0.0]
---
<fetch>~/FETCH_CORE/fetch_core$ rostopic echo -n 1 /joint_states
header: 
  seq: 67623
  stamp: 
    secs: 1526496023
    nsecs: 925422146
  frame_id: ''
name: ['l_gripper_finger_joint', 'r_gripper_finger_joint']
position: [0.004585616290569305, 0.004585616290569305]
velocity: [-1.9669532775878906e-06, -1.9669532775878906e-06]
effort: [0.0, 0.0]
---
<fetch>~/FETCH_CORE/fetch_core$ rostopic echo -n 1 /joint_states
header: 
  seq: 68335
  stamp: 
    secs: 1526496031
    nsecs:  45394137
  frame_id: ''
name: ['l_gripper_finger_joint', 'r_gripper_finger_joint']
position: [0.004585698246955872, 0.004585698246955872]
velocity: [-5.781650543212891e-06, -5.781650543212891e-06]
effort: [0.0, 0.0]
---
<fetch>~/FETCH_CORE/fetch_core$ rostopic echo -n 1 /joint_states
header: 
  seq: 68972
  stamp: 
    secs: 1526496037
    nsecs: 897239020
  frame_id: ''
name: ['l_wheel_joint', 'r_wheel_joint', 'torso_lift_joint', 'bellows_joint', 'head_pan_joint', 'head_tilt_joint', 'shoulder_pan_joint', 'shoulder_lift_joint', 'upperarm_roll_joint', 'elbow_flex_joint', 'forearm_roll_joint', 'wrist_flex_joint', 'wrist_roll_joint']
position: [-6.072175025939941, -0.20786872506141663, 0.002876337617635727, 0.0, 0.008403897285461426, 0.49742796385803223, 1.3199585553100586, 1.4561462151916504, -0.19919875611728668, 0.6295880603637696, -0.0005801878943598269, 2.0636962867053223, 0.0004801792073726649]
velocity: [-1.1920928955078125e-07, 0.0, 2.205371856689453e-06, 1.1026859283447266e-06, 0.0007863044738769531, 0.00018477439880371094, 3.3736228942871094e-05, 0.00017905235290527344, -3.272294998168945e-05, 0.00017309188842773438, -0.00012302398681640625, 5.263090133666992e-05, 0.0006728172302246094]
effort: [-0.0, 0.0, 0.0, 0.0, -0.0, -0.0, -0.0, -0.0, -0.0, -0.0, -0.0, -0.0, -0.0]
---
<fetch>~/FETCH_CORE/fetch_core$ rostopic echo -n 1 /joint_states
header: 
  seq: 69693
  stamp: 
    secs: 1526496044
    nsecs: 625404858
  frame_id: ''
name: ['l_gripper_finger_joint', 'r_gripper_finger_joint']
position: [0.004585575312376022, 0.004585575312376022]
velocity: [6.556510925292969e-07, 6.556510925292969e-07]
effort: [0.0, 0.0]
---

Notice that in two of the above cases, all the links of the Fetch are present. However, in the other cases, only the two gripper joints are present. Here is the corresponding Fetch documentation for the links.

This is a problem because, for instance, when I try to move the robot in code, I can only get the gripper movement to work since it seems like the gripper joints are the ones that are consistently published. The torso, wheels, shoulders, etc., all seem to be unaccessible.

I think (though not sure) that the code I'm using isn't the main issue (which is why I'm not pasting it here). The main problem I think is to figure out why the joint_states topic isn't containing all the correct joints.

In case this helps:

<fetch>~/FETCH_CORE/fetch_core$ rostopic hz /joint_states 
subscribed to [/joint_states]
average rate: 199.688
    min: 0.000s max: 0.165s std dev: 0.01874s window: 176
no new messages
no new messages
average rate: 52.374
    min: 0.000s max: 3.072s std dev: 0.21341s window: 208
average rate: 110.425
    min: 0.000s max: 3.072s std dev: 0.13154s window: 548
average rate: 125.474
    min: 0.000s max: 3.072s std dev: 0.11259s window: 748
average rate: 136.194
    min: 0.000s max: 3.072s std dev: 0.10001s window: 948
average rate: 144.238
    min: 0.000s max: 3.072s std dev: 0.09089s window: 1148
average rate: 150.420
    min: 0.000s max: 3.072s std dev: 0.08385s window: 1349
average rate: 155.401
    min: 0.000s max: 3.072s std dev: 0.07826s window: 1549
average rate: 159.610
    min: 0.000s max: 3.072s std dev: 0.07361s window: 1751
^Caverage rate: 162.966
    min: 0.000s max: 3.072s std dev: 0.06982s window: 1947

This happens after pressing the e-stop button, turning off the breaker, turning off the robot, and then turning the robot on again. I tried the process again but got some similar results.

Is this expected behavior or should I be worried?


Originally posted by DanielSeita on ROS Answers with karma: 46 on 2018-05-16

Post score: 0


Original comments

Comment by gvdhoorn on 2018-05-16:\

Notice that in two of the above cases, all the links of the Fetch are present.

No, they're not. Either the gripper joints are there, or the others.

I don't have a Fetch, but the gripper probably uses a separate JointState publisher, which only publishes for the gripper. The other joints ..

Comment by gvdhoorn on 2018-05-16:
.. are published by another JointState publisher.

That is all perfectly valid and supported. What I don't understand though is why Fetch would configure their robot that way. Typically different publishers would be placed in separate namespaces and joint_state_publisher would be configured ..

Comment by gvdhoorn on 2018-05-16:
.. with the source_list parameter to subscribe to all topics, coalesce the msgs into a single JointState msg and publish that on /joint_states.

You'd have to check the documentation and / or ask Fetch as to why that is not the case here.

Comment by DanielSeita on 2018-05-16:
Sorry, you are are right, I did not read carefully. Yeah it's either the gripper or the joints. Yeah let me look over at the Fetch github repository for ROS (their actual docs don't explain this topic)

Comment by DanielSeita on 2018-05-16:
I found an explanation somewhat https://github.com/cse481wi18/cse481wi18/wiki/Lab-8%3A-Reading-joint-states embarrassed that I didn't see this earlier. The wiki says that each message may only contain a subset of the joints. I see.

Comment by gvdhoorn on 2018-05-16:
I would be very surprised if there was no documentation at all about this topic. I'd really recommend you ask them. If you have one of their robots, you should be entitled to some support, no?

Comment by Moriarty on 2019-08-14:
Yes, all customers are entitled to support, and we're usually busy with the commercial side of things so ROS answers aren't the best way to get help.

I know this is documented somewhere more officially - I'll try to get a link.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

As gvdhoorn mentioned, I made a mistake here, either the gripper joints are there, or the other joints are there.

This is expected behavior. See this Wiki for the reference.

Luckily for us, the robot continuously publishes the current joint angles to the /joint_states topic. However, each message might only contain a subset of the joints. This works because multiple nodes can publish the state of the subset of joints they are responsible for. This is how /joint_states works on the real robot. However, in simulation, all of the joint states are published by Gazebo.

Because no single message on the /joint_states topic will necessarily tell us about all the joints of the robot, we must listen to multiple messages over time and accumulate the full state of the robot. In practice, the joint states are published very quickly, so we will not have to wait long.


Originally posted by DanielSeita with karma: 46 on 2018-05-16

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by gvdhoorn on 2018-05-17:
Note that the wiki you link to is not in any way 'official'. It's just a page on a wiki for a course. I would still recommend to ask Fetch about this.

we must listen to multiple messages over time and accumulate the full state of the robot

as I wrote, there are standard tools that can do ..

Comment by gvdhoorn on 2018-05-17:
.. this for you, no need to implement it in all consumers. But to be able to use those tools, things have to be configured in a certain way. That is where Fetch comes in, as they must have had a reason to configure your robot the way it is.

Comment by DanielSeita on 2018-05-17:
I have contacted Fetch support directly. Thank you for the suggestion.

Comment by gvdhoorn on 2018-05-17:
If/when you get a response, it would be great if you could update your answer.

Comment by Moriarty on 2019-08-14:
I believe the reason the gripper state publishes separately from the rest of the robots states is because the gripper is modular. Other grippers can be purchased from Schunk, Shadow, Robotiq and used on the Fetch, it has the same gripper mount as other commercially available robots.

I agree this needs to be documented somewhere more clearly.

Comment by DanielSeita on 2019-08-14:
Thanks @Moriarty!

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.