RigorMortis's profile - activity

Thanks - that's exactly what I missed!

In the beginner tutorial here:

def handle_add_two_ints(req):
print "Returning [%s + %s = %s]"%(req.a, req.b, (req.a + req.b))
return AddTwoIntsResponse(req.a + req.b)

I understand that the message received will get passed to the 'handle_add_two_ints' function as the object 'req' -- what I do not understand is where the naming convention comes from. They seem to have pulled '.a' and '.b' out of thin air. Can someone please clarify or point me to a site that does? What if I am passing many variables of different types... will they always be alphabetically named?

In the beginner tutorial here:

def handle_add_two_ints(req):
print "Returning [%s + %s = %s]"%(req.a, req.b, (req.a + req.b))
return AddTwoIntsResponse(req.a + req.b)

I understand that the message received will get passed to the 'handle_add_two_ints' function as the object 'req' -- what I do not understand is where the naming convention comes from. They seem to have pulled '.a' and '.b' out of thin air. Can someone please clarify or point me to a site that does? What if I am passing many variables of different types... will they always be alphabetically named?

I managed to figure it out.

The 'remap' command seems to change parameters that the node uses 'from' some original value 'to' a new value specified by the user. In this case, the 'from' parts are correct, but the 'to' parts need to be changed to reflect your particular robot. For example, if your robot's joint_states are being published to /myrobot/joint_states, and if you load your URDF to the parameter server with this line:

<param name="myrobot" textfile="$(find mypackage)/urdf/myrobot.urdf" />

And then you should write the robot state publisher node as below:

<launch>
    <node pkg="robot_state_publisher" type="state_publisher" name="rob_st_pub" >
        <remap from="robot_description" to="myrobot" />
        <remap from="joint_states" to="myrobot/joint_states" />
    </node>
</launch>

*Note that there was also a mistake in the 'node' line of the launch file that I have corrected. I can't be certain that this is correct for all ROS versions, but I can verify that it works on ROS Fuerte perfectly.

LINK TO TUTORIAL

I am trying to figure out how to publish my robot's state using the 'robot_state_publisher'. I fortunately found the tutorial linked to above, but unfortunately the author was rather vague in their example of a launch file (copied below from the tutorial).

<launch>
    <node pkg="robot_state_publisher" type="robot_state_publisher" name="rob_st_pub" >
        <remap from="robot_description" to="different_robot_description" />
        <remap from="joint_states" to="different_joint_states" />
    </node>
</launch>

I would like to know if anyone can better explain what the difference is between 'robot_description' and 'different_robot_description' and exactly what information these are supposed to contain.

Thanks - I posted it there as well.

The problem started yesterday (April 8, 2014) and I believe the guilty update is 'ros-groovy-gazebo-ros-current' but I can't be completely sure since many updates happened at the same time.

Running any gazebo launch file from ROS except the 'empty_world.launch' results in errors and an empty gazebo window. Running my launch file (which has worked for weeks previous to yesterday) results in this output:

ROS_MASTER_URI=http://localhost:11311

core service [/rosout] found process[gazebo-1]: started with pid [8252] process[gazebo_gui-2]: started with pid [8260] process[spawn_smaug-3]: started with pid [8271]

Gazebo multi-robot simulator, version 1.5.0 Copyright (C) 2013 Open Source Robotics Foundation. Released under the Apache 2 License. http://gazebosim.org

Gazebo multi-robot simulator, version 1.5.0 Copyright (C) 2013 Open Source Robotics Foundation. Released under the Apache 2 License. http://gazebosim.org

process[spawn_ramp1-4]: started with pid [8286]

Msg Waiting for master

Msg Waiting for masterprocess[spawn_ramp2-5]: started with pid [8311]

[ INFO] [1397055901.852148927]: waitForService: Service [/gazebo/set_physics_properties] has not been advertised, waiting...  [1;32Msgm MsgConnected to gazebo master @ http://127.0.0.1:11345Connected to gazebo master @ http://127.0.0.1:11345

Msg[1; Publicized address: 32129.107.182.16m

Msg Publicized address: 129.107.182.16

loading model xml from ros parameter

[INFO] [WallTime: 1397055902.297228] [0.000000] waiting for service /gazebo/spawn_urdf_model loading model xml from ros parameter

[INFO] [WallTime: 1397055902.335058] [0.000000] waiting for service /gazebo/spawn_urdf_model

Service call failed: unable to connect to service: [Errno 104] Connection reset by peer

Service call failed: transport error completing service call: unable to receive data from sender, check sender's logs for details

Segmentation fault (core dumped)

[gazebo-1] process has died [pid 8252, exit code 139, cmd /opt/ros/groovy/stacks/simulator_gazebo/gazebo/scripts/gazebo -u /opt/ros/groovy/stacks/simulator_gazebo/gazebo_worlds/worlds/empty.world __name:=gazebo __log:=/home/emrysm/.ros/log/9caa95c0-bff4-11e3-9830-74e50b1cfbaa/gazebo-1.log].

log file: /home/emrysm/.ros/log/9caa95c0-bff4-11e3-9830-74e50b1cfbaa/gazebo-1*.log

loading model xml from ros parameter

[INFO] [WallTime: 1397055902.447661] [0.000000] waiting for service /gazebo/spawn_urdf_model

[spawn_smaug-3] process has finished cleanly

log file: /home/emrysm/.ros/log/9caa95c0-bff4-11e3-9830-74e50b1cfbaa/spawn_smaug-3*.log

[spawn_ramp1-4] process has finished cleanly

log file: /home/emrysm/.ros/log/9caa95c0-bff4-11e3-9830-74e50b1cfbaa/spawn_ramp1-4*.log

[gazebo_gui-2] process has finished cleanly

log file: /home/emrysm/.ros/log/9caa95c0-bff4-11e3-9830-74e50b1cfbaa/gazebo_gui-2*.log