Gazebo | Ignition | Community
Ask Your Question

ahb's profile - activity

2015-02-16 18:36:05 -0500 received badge  Famous Question (source)
2015-02-16 06:28:00 -0500 received badge  Notable Question (source)
2015-02-16 03:06:57 -0500 commented answer Gazebo5 ROS packages?

Hi Nate, thank you for the answer. Of course, it would be great to use and test gazebo5 with Indigo already. However, gazebo4 is working fine for me at the moment. Thus, no hurry on my side.

2015-02-15 23:56:31 -0500 received badge  Popular Question (source)
2015-02-13 07:43:57 -0500 asked a question Gazebo5 ROS packages?

Are there plans to release gazebo5 packages for ROS Indigo (i.e. ros-indigo-gazebo5-*)?

2014-12-12 11:47:00 -0500 received badge  Taxonomist
2014-09-08 22:52:36 -0500 received badge  Famous Question (source)
2014-07-13 11:38:32 -0500 commented answer How do I make a URDF file based on an sdf file?

http://wiki.ros.org/pysdf (sdf2urdf.py) should work quite reliable by now. Please report (on github) if it does not work for you.

2014-07-13 11:35:41 -0500 received badge  Supporter (source)
2014-05-27 05:13:33 -0500 received badge  Notable Question (source)
2014-04-04 17:57:27 -0500 received badge  Popular Question (source)
2014-04-01 11:10:50 -0500 received badge  Student (source)
2014-03-31 10:23:20 -0500 asked a question Gazebo/SDF (vs URDF) and MoveIt/PlanningScene

Hello Gazebo developers and users,

I'd much appreciate your thoughts on how to solve the following issue:

Context:
Robotics lab with multiple ROSified industrial robots that is simulated in Gazebo. Currently, each robot is modeled as .xacro (by xacro), which is converted to .urdf that in turn becomes an .sdf (through gzsdf). The relevant inventory in the lab is modeled as multiple .sdf models (using .dae meshes). SDFs <include> feature is used to combine "ground" .sdf models into larger ones, i.e. a camera SDF together with a camera holder SDF. This is also done in order to attach different items to the robot (cameras, grippers, etc). Finally, a .world file brings together a couple of independent, i.e. not connected by joints, models to make up the whole lab.

This works out quite well, e.g. to change the current gripper I only have to modify one of the "composition" .sdf files - I have a hierarchical set of models that is easy to maintain and adjust to a changed situation in the lab.

Solved issues:

  • Visualize current gazebo world together with simulated sensors in rviz. Use .sdf to contextualize real sensor data with static objects in lab. -> gazebo2rviz

Open issue:

  • MoveIt integration: How to use the current gazebo world as PlanningScene for MoveIt?
    What I want to achieve is the following:
    • Maintain only one description for each entity (automatically converted to other formats if necessary).
    • Have a hierarchy of models, i.e. adding a gripper should not require to redefine the robot it is attached to.
    • Use the same description as basis for MoveIt for the simulated and the real lab.
  • I see the following obstacles - any hint at solving them is greatly appreciated:
    • Where to attach end-effectors in a way that they are valid collision elements and taken into account for path planning? In .xacro, .sdf or add them through custom to the PlanningScene at runtime?
    • Write sdf2moveit and gazebo2moveit (or *2planning_scene) myself? If so, how to properly combine the URDF necessary for MoveIt and the SDF necessary - and to be honest preferred - for gazebo?
    • What to push to TF common to simulation and reality, for simulation only and for real robots only?

To recap: How can we achieve a better integration in different parts (here: Visual and collision models for Gazebo, Rviz and MoveIt) of ROS?

NOTE: I will cross-post this to the moveit mailing list (moveit-users at googlegroups dot com).
Update: here is the post and discussion

Kind regards, ahb

2014-03-02 06:57:04 -0500 commented answer Robot initial configuration

Copy&Paste from the proposal: "My proposal is to have a "<initial>" tag within <joint> that allows to spawn the model with this joint setting as initial value. Setting <initial> to a value != 0 would already alter the way the model is shown when adding it to a world, i.e. before it is registered to physics and before its plugin code is run. In other words the <initial> tag should in this regard behave exactly the same as if the joint's origin where shifted to the initial value."

2014-02-28 02:07:24 -0500 received badge  Editor (source)
2014-02-27 18:00:02 -0500 received badge  Teacher (source)
2014-02-27 18:00:02 -0500 received badge  Necromancer (source)
2014-02-26 02:24:29 -0500 answered a question Robot initial configuration

I now have exactly the same problem. In my case the UR5 robot's 'home position' is defined as (0, -PI/2, 0, -PI/2, 0, 0). I have to initialize the SDF model in this home position, otherwise there will be collisions etc.

Would it be possible to add a <initial> tag to the SDF's <joint> tag, in order to specify the initial position?

I created a proposal to keep track of this feature request.