mz's profile - activity

Hi, thanks for looking over the presentation. For others, the variable can be found by gz sim --help. Also, that variabl

There is some visualization help, if minimal, being upstreamed to Ignition soon https://github.com/osrf/lrauv/issues/111

I don't know much about Gazebo's inner processes, and I've only used SetWorldPose in the context of teleporting a fixed

When you say it doesn't work, can you provide details to what you mean? Is there an error message, and what are the step

If there is any contact that's applying the force to the box, you can visualize the contact force by selecting in the me

If there is any contact that's applying the force to the box, you can visualize the contact force by selecting in the me

Yes, you would need ignition-cmake to use that command. Have you installed the Ignition libraries? This installation tu

There isn't anything built-in to take the sail's area into account, but you can write a custom plugin for the boat's dyn

Thank you for investigating into the underlying cause of the seg fault and posting a solution!

For my specific purpose, which is to teleport a robot, where the robot is kept fixed after teleportation, I’ve found a workaround.

The cause of segmentation fault was likely the call to physics::joint::Detach(). So I avoided calling Detach(). Then there were no more segmentation faults. (Even when I only kept one Detach() call in the entire duration of the Gazebo WorldPlugin, I still had segmentation faults from time to time. So I removed the calls entirely, and then no more seg faults. This further points to Detach() as the problem.)

I still use the Gazebo WorldPlugin, but instead of using Attach() and Detach() to let the robot loose from a fixed "world" link for teleportation, I don’t connect the robot to the world in the URDF at all. I allow the robot to float in space, and I force it still by calling SetWorldPose(teleport_pose) in the OnUpdate() function of the WorldPlugin.

The goal pose for teleportation is passed in from a custom rosservice call. Then OnUpdate() continuously sets the robot’s pose to this goal, and twist to 0 (in case of bumping into something and sliding away in 0 gravity). This effectively achieves my goal, free of seg faults.

Code snippet:

void OnUpdate (const common::UpdateInfo & /*_info*/)
{
  physics::ModelPtr model;

  // Find the model in the Gazebo world
  physics::BasePtr model_genericType = world_ -> GetByName (
    model_name);
  if (model_genericType)
    model = boost::dynamic_pointer_cast <physics::Model> (model_genericType);
  else
    fprintf (stderr, "Did not find model %s.\n", model_name.c_str ());

  if (model)
  {
    //math::Pose pose = ...  // Set some goal pose to teleport to. I set this via a custom rosservice call
    model -> SetWorldTwist (math::Vector3 (), math::Vector3 ());
    model -> SetWorldPose (pose);
  }

  // Check if a rosservice call comes in
  ros::spinOnce ();
}

void Load (physics::WorldPtr _world, sdf::ElementPtr _sdf)
{
  // Check ROS is initialized, subscribe to rosservice, etc. ...

  world_ = _world;
  this -> updateConnection_ = event::Events::ConnectWorldUpdateBegin(
      boost::bind (&MyWorldPlugin::OnUpdate, this, _1));
}

I found a workaround. The objective is to avoid using Detach(), since seg faults are always after it. I simply keep the robot fixed by SetWorldPose() on its base link, in OnUpdate(). This replaces the need to Attach() and Detach() the robot to a fixed joint. I can still teleport it, and keep it fixed after teleport, while its joints can still move freely, just like before. Only difference is, no more seg faults. Thank you so much Andrei for your prompt replies! I will comment if seg fault again.

Hmm I am actually already using a Gazebo plugin, the WorldPlugin, which is how I access physics::World and everything. My rosservices are triggered by calling ros::spinOnce() inside OnUpdate() of the WorldPlugin. I'm not sure what a ROS plugin is. Anyway, I made my code look like Gripper.cc, so instead of Attach(), I call CreateJoint() once at the beginning, then Load() and Init() in the rosservice. But seg faults still happened, still after Detach(). Gripper.cc uses Detach() too.

Tried in ROS Jade with Gazebo 5.1.0. Seg fault happened in a similar way... Do you have any clues on which physics:: object I should look at? Perhaps Joint, or is it something in a bigger scope? I'm contemplating whether to try to fix this by installing Gazebo from source. Otherwise I might have to hunt for a simulator other than Gazebo, which would be redoing a lot of work... Or, perhaps there's some other way to make a robot fixed to the world, without using Attach()?

Gazebo 2.2.6, because I'm using ROS Indigo. Do you mean bug in my code or in Gazebo? Hoping for bug in my code because I need this to work as soon as possible... Otherwise I can try a different Gazebo version that likes ROS Indigo... not sure what else is compatible. I see that it's possible to use 4 5 or 6 if installed from source.

AndreiHaidu: It varies. Looks like ~10 detaches / attaches per minute. I ran the program 11 times, without changing any code, each time until seg fault. These are the numbers I get: 65 detaches / 64 attaches, 36/35, 28/27, 66/65, 16/15, 11/10, 25/24, 109/108, 22/21, 2/1, 96/95. I’ve actually never seen it die after just 2/1 times before, that is rare. It also doesn’t always seg fault in the same place like dQMultiply3() above; another backtrace shows in setBall(). Any ideas?