shobhit6993's profile - activity

I am trying to move the base of PR2 using the Joint Trajectory Controller. This tutorial gives an example of using the Joint Trajectory Action interface to the /r_arm_controller to move the arm. joint_trajectory_action for /r_arm_controller seems to be started by default, as is clear by running the following command to get the names of the joints whose positions need to be specified.

rosparam get /r_arm_controller/joint_trajectory_action/joints

which returns

[r_shoulder_pan_joint, r_shoulder_lift_joint, r_upper_arm_roll_joint, r_elbow_flex_joint, r_forearm_roll_joint, r_wrist_flex_joint, r_wrist_roll_joint]

However, it seems that joint_trajectory_action for base_controller is not started by default. Does a Joint Trajectory Action even exist for the base_controller which I can use to give goal position to the base? If yes, how can I use it?

It seems that the base_controller only has a base_controller/command topic which can be used to move the base with a specified velocity, but for a short (and unspecified) period of time. As I have already asked here, I want control over this period of time for my application if I have to use this approach. If that is not possible, can someone point out how to use the joint_trajectory_action for base_controller?

pr2_controllers provide a low-level robot base controller for moving PR2's base. This tutorial provides a sample usage of the same. The base controller receives Twist messages on the '/base_controller/command' topic which specify the linear and angular velocity of the base. The catch is that a single command makes move the robot move for a short (unspecified) period of time before stopping.

I am using this controller to make the robot move along a path for a certain distance. This tutorial discusses a way to use base_controller to make the robot move a certain distance (by quering the actual distance moved periodically), but the issue with this approach is that the robot might end up overshooting the distance that it is expected to move. While the overshooting might seem insignificant for a single call, I am using this approach over a long path, and the errors get compounded to intolerable levels.

Is there a way to specify the period of time associated with one call to the base_controller/command? Or, is there some other way to tackle this problem?

In case it matters, I am using ROS Groovy on Ubuntu 12.04 (Presence of legacy code and package dependencies in my project have forced me to fallback to Groovy)

The Move Group Interface in MoveIt provides a computeCartesianPath function for planning a cartesian path directly by specifying a list of waypoints for the end-effector to go through. I assume that the function internally does Inverse Kinematics to compute the velocity/acceleration of joints. Is there a similar function that allows me to specify the waypoints as well as the velocity of end-effector? In particular, I want to move only the base of PR2 to follow a trajectory specified by a set of waypoints, along with the velocity of the base at each timestep.

If not, is there any other way (potentially outside of MoveIt) through which I can achieve this?

Done. This marks my first contribution to any wiki :)

I finally got it to work. I guess the issue was that I was setting the use_sim_time parameter after the launch command, because of which the nodes (already launched) did not get the information that they are supposed to use the simulated clock.

One thing I would like to point out is that the tutorial indeed indeed asks you to set use_sim_time before the roslaunch command. When I initially tried to do this, I got the following error

ERROR: Unable to communicate with master!

because, obviously, the master was not running. I feel quite dumb now, but this is kind of what happens when you blindly follow the sequence mentioned in the tutorial, and not use common sense. The tutorial skips the instruction to first run roscore (to get the Master running). The roslaunch command itself starts the Master, if one is not running; but without setting the use_sim_time parameter to true.

In case someone falls into this silly pit in future, the following are the correct sequence of commands to get around this issue:

roscore

rosparam set /use_sim_time true

roslaunch openni_launch openni.launch load_driver:=false

rosrun rviz rviz (to launch rviz for visualization, or any other method to see the messages being played back)

rosbag play --clock --pause kinectbag.bag

(ROS Hydro on Ubuntu 12.04)

I am following the tutorial on Recording and Playing Back Kinect Data. First, I recorded a rosbag file using

rosbag record camera/depth_registered/image_raw camera/depth_registered/camera_info camera/rgb/image_raw camera/rgb/camera_info --limit=60 -O kinectbag

As suggested in the tutorial, before playing back, I need to set the use_sim_time parameter. To do this, first I launch openni_launch without loading drivers

roslaunch openni_launch openni.launch load_driver:=false

Then, I set the parameter with

rosparam set /use_sim_time true

and confirmed that the parameter has indeed been set with the rosparam get /use_sim_time command (which returns true). I am trying to visualize the playback in rviz (added PointCloud2 to rviz with appropriate Fixed Frame and topic settings) using following playback command

rosbag play --clock --pause kinectbag.bag

At this point, the Status of PointCloud2 shows an error saying

Transform [sender=/camera/camera_nodelet_manager] Message removed because it is too old (frame=[/camera_rgb_optical_frame], stamp=[1442173625.519280128])

and a warning is printed on the terminal (from which I invoked rviz)

[ WARN] [1442177967.606387020, 1442173623.553857221]: Detected jump back in time. Clearing TF buffer.

I can see that prior to loading the rosbag play command, the ROS time in rviz is set to 0, and it changes to the timestamp of the first message in my rosbag recording after I issue the play command (hence, it is indeed using simulated time, and not wall time).

Can anyone point out what might be causing this error?

P.S: I know that hundreds of similar queries have been answered before here, but they all are resolved by setting the use_sim_time parameter. In my case, I am facing the issue in spite of doing that.