ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

JaredMoore's profile - activity

2021-07-14 03:42:01 -0500 received badge  Nice Answer (source)
2020-08-20 15:07:51 -0500 received badge  Self-Learner (source)
2020-08-20 15:07:51 -0500 received badge  Teacher (source)
2018-07-17 08:14:03 -0500 received badge  Taxonomist
2017-10-05 06:02:09 -0500 received badge  Student (source)
2017-07-09 22:50:46 -0500 received badge  Famous Question (source)
2017-06-01 09:09:48 -0500 received badge  Famous Question (source)
2017-02-16 21:31:17 -0500 received badge  Notable Question (source)
2016-11-20 11:20:55 -0500 received badge  Notable Question (source)
2016-08-31 23:03:27 -0500 received badge  Popular Question (source)
2016-08-31 11:52:52 -0500 answered a question How to Run Multiple Gazebo Simulations with Unique Clocks

The solution should be to use the <remap> tag and remap /clock per group. However, on Kinectic there seems to be a problem with this currently. See question http://answers.ros.org/question/24265... for a detailed look at the problem.

2016-08-31 11:01:57 -0500 received badge  Famous Question (source)
2016-08-31 10:02:50 -0500 commented answer Is it possible to remap /clock?

Tested the code on my local VM with Indigo/Gazebo2. Works here as well. Appears that possibly they've broken something between versions. I went ahead and added a github issue to the repository. Thanks for the help here, looks like I might have to go there to get the issue resolved.

2016-08-31 09:15:21 -0500 commented answer Is it possible to remap /clock?

Great, thanks for the quick reply! I just tried changing the world to use empty world as well but still no success. I'm wondering if they inadvertently broke something on Gazebo7/Kinectic. I launched the file and then used rostopic list. The /clock topic was there, but no remapped one.

2016-08-31 08:47:59 -0500 commented answer Is it possible to remap /clock?

Just tried using this configuration using the launch and world file in my Edit 2. Any chance you could take a look, maybe try those on your system to see if the remapping works? It has failed on my two test systems. Thanks for the help!

2016-08-30 14:36:23 -0500 received badge  Notable Question (source)
2016-08-30 13:21:55 -0500 received badge  Editor (source)
2016-08-30 13:20:11 -0500 commented answer Is it possible to remap /clock?

Thanks for the help, I've edited my question as I think there might be an issue with remapping clock in gazebo nodes.

2016-08-30 07:40:48 -0500 received badge  Enthusiast
2016-08-29 15:09:40 -0500 received badge  Popular Question (source)
2016-08-29 14:57:01 -0500 commented answer Is it possible to remap /clock?

I think I'm being a bit dense but I looked around and ran rostopic info. All I see for a name is /clock. Im my setup file I currently do not have anything inside group tags to avoid any possible problems there. Any more info on absolute names? Sorry and thanks for the help!

2016-08-29 12:48:13 -0500 commented answer Is it possible to remap /clock?

Tried to remap /clock instead of clock as suggested and variants of groupX_clock as well as /groupX_clock. For the first configuration (/clock,groupX_clock) no updates occurred at all. Adding / to groupX published back on the clock topic, remap seems to fail.

2016-08-29 11:18:21 -0500 asked a question Is it possible to remap /clock?

I'm running a launch file with grouped gazebo instances. So far I've been able to successfully separate each group into its own container, however, the \clock topic is still being shared among the groups. I've inserted a <remap from="clock" to="groupX_clock"/> following the conventions in http://wiki.ros.org/roslaunch/XML/remap . After launching, it appears that the clock is not being remapped correctly and the different Gazebo nodes use the same clock topic, leading to collisions in messages and errors mentioning that the simulation has moved back in time.

Is there an undocumented restriction on remapping certain topics? Or perhaps (most likely) I have just missed a critical piece of information.

Thanks!

Edit 1

After the comments posted in dornhege's answer, I've tried quite a few variations and investigated using rostopic list, rostopic info, and gz topic -l. It appears that the clock topic is remapped correctly in all but the Gazebo node. Something appears to be hindering the remapping there, but I'm am currently unsure how to get it to work correctly.

Edit 2

I've created a simplified set of launch and world files to try and isolate where I might be running into a problem. Here is my gazebo_only.launch file:

<launch>

<!-- ********************* Begin Gazebo Defaults ******************************** -->

<arg name="args" default="--verbose -r -e ode"/>
<arg name="world" value="$(find basicbot_gazebo)/worlds/empty.world"/>

<!-- set use_sim_time flag -->
<!--<param name="/use_sim_time" value="true" />-->


<!-- ********************* End Gazebo Defaults ******************************** -->    


<!-- start gazebo server-->
<!--<env name="GAZEBO_MASTER_URI" value="http://localhost:11345"/>-->
<node name="gazebo" pkg="gazebo_ros" type="gzserver" args="$(arg world) $(arg args)" respawn="false" output="screen">
  <remap from="rosout" to="rosout_remapped" />  
  <remap from="clock" to="clock_remapped" />
</node>

</launch>

Here is my world file:

<?xml version="1.0" ?>
<sdf version="1.5">
  <world name="default">
    <physics type="ode">
          <max_step_size>0.025</max_step_size>
        <real_time_update_rate>30</real_time_update_rate>
    </physics>

    <include>
      <uri>model://ground_plane</uri>
    </include>
  </world>
</sdf>

I've tried launching this on both my remote system, and my local Ubuntu VM both running Kinectic and Gazebo7. The remapping of both topics in the gazebo node still appears to fail. Does it work on your system?

Edit 3

Opened a github issue in the gazebo_ros_pkgs repository ( https://github.com/ros-simulation/gaz... ) after considering Stefan's post. Verified myself that the code works in Indigo/Gazebo2 but not Kinectic/Gazebo7.

2016-08-26 08:50:01 -0500 asked a question How to Run Multiple Gazebo Simulations with Unique Clocks

As a follow on to my previous question: http://answers.ros.org/question/24100...

I'm trying to run multiple Gazebo simulations on one machine, using the <group> tag to encapsulate each simulation within its own namespace. So far, this works fine. I'm able to launch the simulations, the robot URDF is loaded and parsed and the simulations proceed.

However, I'm running into one outstanding issue which I am unsure how to/if it can be addressed. For example, if I run four separate Gazebo simulations, each in their own namespaced group, the /clock topic is not namespaced. Therefore, each of the four simulations is writing and reading from a common clock leading to synchronization problems and incorrect simulation times. One simulation might run smoothly, but another might jump around timewise depending on how the underlying operating system schedules the processes.

This leads to wildly unpredictable results and invalid simulations.

Is there a way to place the /clock within the scope of a <group> tag? I've been unable to find an example or documentation of this after a fairly comprehensive search. I'm almost thinking that it is not possible, but will wait for confirmation.

Thanks!

2016-08-23 20:52:03 -0500 received badge  Famous Question (source)
2016-08-04 11:07:02 -0500 received badge  Popular Question (source)
2016-08-04 08:41:30 -0500 commented answer Gazebo topic publication issue within namespaced group tag

Not enough points to accept this as an answer, but it is the fix.

2016-08-04 08:41:04 -0500 answered a question Gazebo topic publication issue within namespaced group tag

I was able to solve this issue this morning. I did not end up needing the robotName or robotNamespace tags as suggested. Instead, my issue was due to the fact that gazebo was launching as /ga1/gazebo, forcing the services it offered to be changed from /gazebo/<service> to /ga1/gazebo/<service>. The launch file was still however looking for /gazebo/<service>, especially in the case of the urdf_spawn node. Accordingly, I changed

<node name="urdf_spawner" pkg="gazebo_ros" type="spawn_model" respawn="false" output="screen"
    args="-urdf -model basicbot -param robot_description"/>

to

<node name="urdf_spawner" pkg="gazebo_ros" type="spawn_model" respawn="false" output="screen"
    args="-urdf -model basicbot -param robot_description -gazebo_namespace /ga1/gazebo"/>

by adding the -gazebo_namespace /ga1/gazebo attribute at the end of the call. Be sure also to make changes to any scripts that use rospy and wait_for_service or ServiceProxy as you will need to prepend the namespace to those as well by calling rospy.get_namespace().

2016-08-04 07:41:38 -0500 commented answer Gazebo topic publication issue within namespaced group tag

Thank you for the suggestion, I have made the advised changes but am still running into the same issue. I suspect that I will need the proposed changes as well so I have left them in. See Edit 1 for an explanation. It seems some parts of Gazebo are not starting or are lost in a ns conflict.

2016-08-03 08:23:26 -0500 received badge  Organizer (source)
2016-08-03 08:09:15 -0500 asked a question Gazebo topic publication issue within namespaced group launch tag.

ROS Kinetic
Gazebo 7.0
RedHat Linux

I'm running into an issue with a roslaunch file that attempts to start a Gazebo node within a group tag that has the namespace parameter set. The Gazebo node appears to start, but other nodes that wait on gazebo services hang. Specifically, when using rospy, the following calls do not complete.

rospy.wait_for_service('/gazebo/get_world_properties')
rospy.wait_for_service('/gazebo/reset_world')
rospy.wait_for_service('/gazebo/reset_simulation')
rospy.wait_for_service('/gazebo/pause_physics')
rospy.wait_for_service('/gazebo/unpause_physics')

The launch file is as follows:

<launch>

<!-- ********************* Begin Gazebo Defaults ******************************** -->

<!-- these are the arguments you can pass this launch file, for example paused:=true -->
  <arg name="paused" default="true"/>
  <arg name="use_sim_time" default="true"/>
  <arg name="gui" default="false"/>
  <arg name="headless" default="true"/>
  <arg name="debug" default="false"/>

  <!-- these are the arguments you can pass this launch file, for example paused:=true -->
  <arg name="extra_gazebo_args" default=""/>
  <arg name="physics" default="ode"/>
  <arg name="verbose" default="true"/>
  <arg name="world_name" value="$(find basicbot_gazebo)/worlds/basicbot.world"/>
  <arg name="respawn_gazebo" default="false"/>
  <arg name="use_clock_frequency" default="false"/>
  <arg name="pub_clock_frequency" default="100"/>

  <!-- set use_sim_time flag -->
  <group if="$(arg use_sim_time)">
    <param name="/use_sim_time" value="true" />
  </group>

  <!-- set command arguments -->
  <arg unless="$(arg paused)" name="command_arg1" value=""/>
  <arg     if="$(arg paused)" name="command_arg1" value="-u"/>
  <arg unless="$(arg headless)" name="command_arg2" value=""/>
  <arg     if="$(arg headless)" name="command_arg2" value="-r"/>
  <arg unless="$(arg verbose)" name="command_arg3" value=""/>
  <arg     if="$(arg verbose)" name="command_arg3" value="--verbose"/>
  <arg unless="$(arg debug)" name="script_type" value="gzserver"/>
  <arg     if="$(arg debug)" name="script_type" value="debug"/>

  <group if="$(arg use_clock_frequency)">
    <param name="gazebo/pub_clock_frequency" value="$(arg pub_clock_frequency)" />
  </group>

<!-- ********************* End Gazebo Defaults ******************************** -->    

<!-- <group ns="basicbot_ga_1"> -->
<group ns="ga1">
  <!-- start gazebo server-->
  <env name="GAZEBO_MASTER_URI" value="http://localhost:11345"/>
  <node name="gazebo" pkg="gazebo_ros" type="$(arg script_type)" respawn="$(arg respawn_gazebo)" 
    output="screen" args="$(arg command_arg1) $(arg command_arg2) $(arg command_arg3) -e $(arg physics) 
    $(arg extra_gazebo_args) $(arg world_name)">
  </node>

  <!-- Load the transporter node -->
  <node name="basicbot_transporter" pkg="basicbot_ga" type="basicbot_transporter.py" output="screen"></node>

    <!-- Load the turn_drive_scan node -->
    <node name="turn_drive_scan" pkg="basicbot_ga" type="turn_drive_scan_node.py" output="screen"></node>

    <!-- Load the step world node -->
  <node name="step_world" pkg="world_step" type="step_world_server"/>

  <!-- Load the URDF into the ROS Parameter Server -->
  <param name="robot_description"
    command="$(find xacro)/xacro '$(find basicbot_description)/urdf/basicbot.xacro'" />

  <!-- Run a python script to the send a service call to gazebo_ros to spawn a URDF robot -->
  <node name="urdf_spawner" pkg="gazebo_ros" type="spawn_model" respawn="false" output="screen"
    args="-urdf -model basicbot -param robot_description"/>
</group>

</launch>

I've tried the following while troubleshooting the problem.

  1. Remove group tag completely. Behavior: Simulation runs fine, nodes initialize and execute after the initial spool up.
  2. Add group tag without ns attribute. Behavior: Simulation again runs fine.
  3. Add ns attribute. Behavior: Gazebo node appears to launch, but the previously mentioned services do not appear to be available to other nodes inside the group tag. rostopic list and gz topic -l do not show the topics being published either.

As far as I can tell, adding the ... (more)

2016-08-03 08:08:17 -0500 asked a question Gazebo topic publication issue within namespaced group tag

ROS Kinetic
Gazebo 7.0
RedHat Linux

I'm running into an issue with a roslaunch file that attempts to start a Gazebo node within a group tag that has the namespace parameter set. The Gazebo node appears to start, but other nodes that wait on gazebo services hang. Specifically, when using rospy, the following calls do not complete.

rospy.wait_for_service('/gazebo/get_world_properties')
rospy.wait_for_service('/gazebo/reset_world')
rospy.wait_for_service('/gazebo/reset_simulation')
rospy.wait_for_service('/gazebo/pause_physics')
rospy.wait_for_service('/gazebo/unpause_physics')

The launch file is as follows:

<launch>

<!-- ********************* Begin Gazebo Defaults ******************************** -->

<!-- these are the arguments you can pass this launch file, for example paused:=true -->
  <arg name="paused" default="true"/>
  <arg name="use_sim_time" default="true"/>
  <arg name="gui" default="false"/>
  <arg name="headless" default="true"/>
  <arg name="debug" default="false"/>

  <!-- these are the arguments you can pass this launch file, for example paused:=true -->
  <arg name="extra_gazebo_args" default=""/>
  <arg name="physics" default="ode"/>
  <arg name="verbose" default="true"/>
  <arg name="world_name" value="$(find basicbot_gazebo)/worlds/basicbot.world"/>
  <arg name="respawn_gazebo" default="false"/>
  <arg name="use_clock_frequency" default="false"/>
  <arg name="pub_clock_frequency" default="100"/>

  <!-- set use_sim_time flag -->
  <group if="$(arg use_sim_time)">
    <param name="/use_sim_time" value="true" />
  </group>

  <!-- set command arguments -->
  <arg unless="$(arg paused)" name="command_arg1" value=""/>
  <arg     if="$(arg paused)" name="command_arg1" value="-u"/>
  <arg unless="$(arg headless)" name="command_arg2" value=""/>
  <arg     if="$(arg headless)" name="command_arg2" value="-r"/>
  <arg unless="$(arg verbose)" name="command_arg3" value=""/>
  <arg     if="$(arg verbose)" name="command_arg3" value="--verbose"/>
  <arg unless="$(arg debug)" name="script_type" value="gzserver"/>
  <arg     if="$(arg debug)" name="script_type" value="debug"/>

  <group if="$(arg use_clock_frequency)">
    <param name="gazebo/pub_clock_frequency" value="$(arg pub_clock_frequency)" />
  </group>

<!-- ********************* End Gazebo Defaults ******************************** -->    

<!-- <group ns="basicbot_ga_1"> -->
<group ns="ga1">
  <!-- start gazebo server-->
  <env name="GAZEBO_MASTER_URI" value="http://localhost:11345"/>
  <node name="gazebo" pkg="gazebo_ros" type="$(arg script_type)" respawn="$(arg respawn_gazebo)" 
    output="screen" args="$(arg command_arg1) $(arg command_arg2) $(arg command_arg3) -e $(arg physics) 
    $(arg extra_gazebo_args) $(arg world_name)">
  </node>

  <!-- Load the transporter node -->
  <node name="basicbot_transporter" pkg="basicbot_ga" type="basicbot_transporter.py" output="screen"></node>

    <!-- Load the turn_drive_scan node -->
    <node name="turn_drive_scan" pkg="basicbot_ga" type="turn_drive_scan_node.py" output="screen"></node>

    <!-- Load the step world node -->
  <node name="step_world" pkg="world_step" type="step_world_server"/>

  <!-- Load the URDF into the ROS Parameter Server -->
  <param name="robot_description"
    command="$(find xacro)/xacro '$(find basicbot_description)/urdf/basicbot.xacro'" />

  <!-- Run a python script to the send a service call to gazebo_ros to spawn a URDF robot -->
  <node name="urdf_spawner" pkg="gazebo_ros" type="spawn_model" respawn="false" output="screen"
    args="-urdf -model basicbot -param robot_description"/>
</group>

</launch>

I've tried the following while troubleshooting the problem.

  1. Remove group tag completely. Behavior: Simulation runs fine, nodes initialize and execute after the initial spool up.
  2. Add group tag without ns attribute. Behavior: Simulation again runs fine.
  3. Add ns attribute. Behavior: Gazebo node appears to launch, but the previously mentioned services do not appear to be available to other nodes inside the group tag. rostopic list and gz topic -l do not show the topics being published either.

As far as I can tell, adding the ... (more)

2016-07-28 10:13:44 -0500 received badge  Notable Question (source)
2016-07-28 10:13:44 -0500 received badge  Popular Question (source)
2016-07-26 08:01:30 -0500 commented question How to gazebo master uri in roslaunch file?

I'm using Kinetic myself and trying to figure this exact issue out. It appears that using the <env> tag within a node, or within a group sets the URI correctly for one, but not two groups. For example, I cannot set the URI for two separate gzservers, even though this is possible from the cmd line.

2016-07-26 07:59:52 -0500 received badge  Supporter (source)
2016-04-14 14:57:33 -0500 asked a question ROS-Gazebo Configuration for Deterministic Simulation

I'm currently working on setting up my ROS-Gazebo environment and have encountered a problem that I can't seem to find the answer to. When running a test of dropping a sphere onto a box, the endpoint of the sphere after 4 seconds of simulation time has an element of randomness to it. This will prevent me from being able to use the simulation for my intended purpose (evolutionary robotics).

I've previously used the Open Dynamics Engine in my past research with it running deterministically after setting the random number seed. Accordingly, I am attempting to do the same with ROS-Gazebo and have found what I think are the appropriate settings. I detail them below.

First, I use a piece of code to step the Gazebo simulation in sync with ROS so there shouldn't be a desync issue between the two components. The code is:

#include <math.h>
#include <boost/thread.hpp>
#include <boost/algorithm/string.hpp>

#include <gazebo/gazebo.hh>
#include <gazebo/common/Plugin.hh>
#include <gazebo/msgs/msgs.hh>
#include <gazebo/transport/transport.hh>
#include <gazebo_msgs/LinkStates.h>

#include <ros/ros.h>
#include <ros/subscribe_options.h>

int main(int argc, char** argv)
{
  gazebo::setupClient(argc,argv);
  ros::init(argc, argv, "get_world_time_test");

  // Gazebo WorldControl Topic
  gazebo::transport::NodePtr node(new gazebo::transport::Node());
  node->Init();

  // Gazebo ServerControl Topic
  gazebo::transport::NodePtr serverNode(new gazebo::transport::Node());
  serverNode->Init();

  // Initialize the ROSNode
  ros::NodeHandle* rosnode = new ros::NodeHandle();

  // Gazebo Publishers
  gazebo::transport::PublisherPtr pub = node->Advertise<gazebo::msgs::WorldControl>("~/world_control");

  gazebo::transport::PublisherPtr serverPub = serverNode->Advertise<gazebo::msgs::ServerControl>("/gazebo/server/control");

  // Waits for simulation time update.
  ros::Time last_ros_time_;
  bool wait = true;
  while (wait)
  {
    last_ros_time_ = ros::Time::now();

    if (last_ros_time_.toSec() > 0) {
      if (last_ros_time_.toSec() >= 2.0) {
        //Removed code to print position of ball to the screen.
      }
    }    

    // Publish the step message for the simulation.
    gazebo::msgs::WorldControl msg;
    msg.set_step(1);
    pub->Publish(msg);

    // Wait for 1 second and allow ROS to complete as well.
    gazebo::common::Time::MSleep(5);
    ros::spinOnce();
  }

  // Send a server control shutdown message.
  gazebo::msgs::ServerControl serverMsg;
  serverMsg.set_stop(1);
  serverPub->Publish(serverMsg);

  return 0;
}

Second, I set the seed of Gazebo in my launch file to 1 so each simulation should be initialized with the same random number seed. In my previous experience, this was enough to have ODE run deterministically for the same robot and controller in multiple simulations. (The robot would move along the same path and the same distance provided it ran for the same amount of simulation time.) The launch file is as follows:

<launch>
  <arg name="paused" default="true"/>
  <arg name="use_sim_time" default="true"/>
  <arg name="gui" default="true"/>
  <arg name="headless" default="false"/>
  <arg name="debug" default="false"/>
  <arg name="world_name" default="$(find firstbot_gazebo)/worlds/firstbot_world.world"/> 

  <!-- set use_sim_time flag -->
  <group if="$(arg use_sim_time)">
    <param name="/use_sim_time" value="true" />
  </group>

  <!-- set command arguments -->
  <arg unless="$(arg paused)" name="command_arg1" value=""/>
  <arg     if="$(arg paused)" name="command_arg1" value="-u"/>
  <arg unless="$(arg headless)" name="command_arg2 ...
(more)