Gazebo | Ignition | Community
Ask Your Question
0

drcsim: keyboard_teleop hangs at line 75 self.client.wait_for_server()

asked 2013-05-01 12:36:04 -0500

dcconner gravatar image

updated 2013-05-01 18:16:19 -0500

The keyboard_teleop walking demo works on some machines, and on others it hangs at line 75

self.client.wait_for_server()

I tried sudo apt-get remove and reinstall drcsim-nightly but that didn't solve the issue.

Anyone else seen this? Is there some dependency that must be installed separately?

I was told this can indicate that the actionlib server didn't start properly; the log file shows:

rospy.client][INFO] 2013-05-01 18:01:31,018: init_node, name[/walking_client], pid[7581]
[xmlrpc][INFO] 2013-05-01 18:01:31,018: XML-RPC server binding to 0.0.0.0:0
[xmlrpc][INFO] 2013-05-01 18:01:31,018: Started XML-RPC server [http://computer:57220/]
[rospy.init][INFO] 2013-05-01 18:01:31,018: ROS Slave URI: [http://computer:57220/]
[rospy.impl.masterslave][INFO] 2013-05-01 18:01:31,018: _ready: http://computer:57220/
[xmlrpc][INFO] 2013-05-01 18:01:31,019: xml rpc node: starting XML-RPC server
[rospy.registration][INFO] 2013-05-01 18:01:31,019: Registering with master node http://localhost:11311
[rospy.init][INFO] 2013-05-01 18:01:31,119: registered with master
[rospy.rosout][INFO] 2013-05-01 18:01:31,119: initializing /rosout core topic
[rospy.rosout][INFO] 2013-05-01 18:01:31,122: connected to core topic /rosout
[rospy.simtime][INFO] 2013-05-01 18:01:31,124: initializing /clock core topic
[rospy.simtime][INFO] 2013-05-01 18:01:31,126: connected to core topic /clock
[rospy.internal][INFO] 2013-05-01 18:01:31,137: topic[/clock] adding connection to [http://computer:56967/], count 0
[rosout][INFO] 2013-05-01 18:01:31,143: Waiting for atlas/bdi_control
[rospy.internal][INFO] 2013-05-01 18:01:31,254: topic[/atlas/mode] adding connection to [/gazebo], count 0
[rospy.internal][INFO] 2013-05-01 18:01:31,353: topic[/rosout] adding connection to [/rosout], count 0
[rospy.internal][INFO] 2013-05-01 18:01:31,354: topic[/atlas/control_mode] adding connection to [/gazebo], count 0

That's the output of the walking_client.log; the only message on screen is the "Waiting for atlas/bdi_control" message

edit retag flag offensive close merge delete

4 Answers

Sort by ยป oldest newest most voted
0

answered 2013-05-01 19:20:50 -0500

hsu gravatar image

did you start keyboard teleop by roslaunch? i.e.

roslaunch atlas_utils keyboard_teleop.launch 

alternatively, be sure to start actionlib_server first,

rosrun atlas_msgs actionlib_server 

then do

roslaunch atlas_utils keyboard_teleop.launch 
edit flag offensive delete link more

Comments

:-( This is where I'm tempted to toss this post down the memory hole. When in doubt carefully read instructions, and don't go from memory and use "rosrun" instead "roslaunch". Thanks. Must have had 5steps.py in my head.

dcconner gravatar imagedcconner ( 2013-05-01 20:30:29 -0500 )edit
0

answered 2013-06-04 12:19:07 -0500

eric gravatar image

/chatter works as expected if published on sim (remote), and then echo'd on either sim or ocs (local).

However, if I pub /chatter on ocs, then echo on ocs works, but echo on sim does not. However, on sim, it does see that the /chatter topic is active. Below is the error message from the remote sim machine, when the /chatter topic was published on the ocs local machine :

ubuntu@sim-xx:~$ rostopic echo /chatter WARNING: no messages received and simulated time is active. Is /clock being published? ^Cubuntu@sim-xx:~$ rostopic list | grep chatter /chatter ubuntu@sim-xx:~$

edit flag offensive delete link more

Comments

That sounds like the `ROS_IP` environment variable is not set correctly on the OCS/OCU. That variable should be set by the router-provided `ros.bash` file to be 11.8.0.2, which means that subscribers will come find your publishers at that address. Did you source `ros.bash`? Can you check the value of `ROS_IP`?

gerkey gravatar imagegerkey ( 2013-06-04 12:54:01 -0500 )edit

To help debug, try, on the sim machine: `rostopic info /chatter`. It will list the known publishers, with their XMLRPC URIs. Make sure that your OCS/OCU publisher is listed with 11.8.0.2 as its hostname.

gerkey gravatar imagegerkey ( 2013-06-04 12:55:38 -0500 )edit

Thanks for the debugging tip, it looks like I have solved the problem.

eric gravatar imageeric ( 2013-06-06 13:08:48 -0500 )edit

Seems like a tutorial on how to setup GAZEBO\_IP, GAZEBO\_MASTER\_URI, ROS\_IP, ROS\_MASTER\_URI could exist on http://gazebosim.org/wiki/CloudSim/VRCUserGuide?

hsu gravatar imagehsu ( 2013-06-06 17:45:54 -0500 )edit
0

answered 2013-06-01 20:26:43 -0500

eric gravatar image

updated 2013-06-03 22:39:03 -0500

gerkey gravatar image

This helps explain a solution, but I still see the same problem when running across machines using Cloudsim. Here is what I tried to isolate the issue: on sim machine,

$ roslaunch atlas_utils qual_task_1, 
terminal 2 $ rosrun atlas_msgs actionlib_server, 
terminal 3 $ roscd to : atlas_utils/scripts
$./keyboard_teleop.py

the above works as expected, I can control atlas with keyboard telop running on sim machine, gzserver running on sim, and watch atlas using gzclient on local machine.

Now trying the same thing but running keyboard_teleop on local machine :

in ~/vrc_credentials/router_OSRF_VRC_Constellation_37$ . ros.bash
$ roscd atlas_utils/scripts
$ ./keyboard_teleop.py 
 -->  [INFO] [WallTime: 1370135686.288958] [540.776000] Waiting for atlas/bdi_control

now if I Ctrl-C out of this, and then in a second local terminal window (after . ros.bash)

terminal 2  $ rosrun atlas_msgs actionlib_server  
this runs as expected on the local machine, and the actionlib server node is shut down on the sim machine as shown by: [ WARN] [1370135894.701704488, 722.701000000]: Shutdown request received.
[ WARN] [1370135894.701758224, 722.701000000]: Reason given for shutdown: [new node registered with same name]

now I try again to run on the local machine:

teminal 1 $./keyboard_teleop.py
I still end up waiting for the actionlib_server as shown by :
[INFO] [WallTime: 1370136073.442231] [878.275000] Waiting for atlas/bdi_control

so in conclusion, I can run keyboard teleop remotely on the sim machine as I can on my local machine, but if I split up the simulation on the sim machine, and keyboard teleop on the local machine, I am not able to get past keyboard_teleop looking for the actionlib_server testing both cases of the actionlib_server running on either the sim or the local.

edit flag offensive delete link more

Comments

Sounds like something is wrong with the ROS configuration. Can you do something simpler, like running rostopic pub /chatter std_msgs/String foo on one side and rostopic echo /chatter on the other? Try it both ways.

gerkey gravatar imagegerkey ( 2013-06-03 22:58:33 -0500 )edit
0

answered 2013-06-06 13:16:38 -0500

eric gravatar image

updated 2013-06-06 17:32:43 -0500

gerkey gravatar image

Problem solved :

Your debugging hints helped quite a bit :

ubuntu@sim-37:~$ rostopic info /chatter
Type: std_msgs/String

Publishers: 
 * /rostopic_12677_1370540962545 (http://10.0.0.51:46246/)
 * /rostopic_11096_1370542055112 (http://ubuntu:46317/)

Subscribers: 
 * /rostopic_15784_1370541247997 (http://10.0.0.51:60880/)
 * /rostopic_11085_1370542031830 (http://11.8.0.2:47065/)

While ros.bash on OCS did change the ROS_IP, and also ROS_MASTER_URI, it appears that we also need to change : ROS_HOSTNAME. in the OCS terminal I changed ROS_HOSTNAME for ubuntu to : 10.8.0.2, and now the OCS and sim computers communicate as expected. I will now edit the ros.bash file located in the router_OSRF_VRC_Constellation_XX directory.

edit flag offensive delete link more

Question Tools

1 follower

Stats

Asked: 2013-05-01 12:36:04 -0500

Seen: 574 times

Last updated: Jun 06 '13