Gazebo | Ignition | Community
Ask Your Question

Gwen's profile - activity

2016-03-17 07:43:59 -0600 received badge  Nice Answer (source)
2014-05-21 01:09:57 -0600 received badge  Famous Question (source)
2014-03-02 13:15:35 -0600 received badge  Notable Question (source)
2014-02-27 16:25:11 -0600 received badge  Popular Question (source)
2014-02-27 11:25:12 -0600 commented question Modeling Omni Wheels

This question is on a related topic: ...seems like something is up (or at least misunderstood) with the <fdir1> tag.

2014-02-27 11:16:33 -0600 received badge  Supporter (source)
2014-02-26 11:15:55 -0600 commented question Parameters for a skid steering/simulated tracked robot (use of the fdir1 tag)

This seems to be related the question I just asked about omni-wheel modeling and fdir1/mu not working properly. ( I'll link back to this question as well.

2014-02-26 10:42:26 -0600 asked a question Modeling Omni Wheels

I would like to model an omni wheel. Ideally, I would like to do this using non-uniform friction properties (see below). However, it seems like the contact algorithm is not properly accounting for the fdir1 parameter, as setting either <mu1> or <mu2> to zero causes the wheel to slip when rotating. There are a few other threads regarding omni wheels that are a few years old, but I haven't found a satisfactory answer--I have seen this method of friction modification suggested, but no examples of successful implementation.

omni-wheel macro: z-axis is axial direction.

<link name="${wheel_name}">
        <mass value="${wheel_mass}"/>
        <origin xyz="0 0 0" rpy="0 0 0"/>
        <inertia ixx="${ixx}" iyy="${iyy}" izz="${izz}" ixy="${ixy}" ixz="${ixz}" iyz="${iyz}"/>
    <visual name="${wheel_name}_vis">
        <origin xyz="0 0 0.05" rpy="0 0 0"/>
        <geometry name="${wheel_name}_geom">
            <!-- <cylinder length="0.025" radius="${wheel_radius}"/> -->
            <mesh filename="${wheel_visual}"/>
    <collision name="${wheel_name}_col">
         <origin xyz="0 0.0 0" rpy="0 0 0"/>
         <geometry name="${wheel_name}_geom">
            <cylinder length="0.025" radius="${wheel_radius}"/>
            <!-- <sphere radius="${wheel_radius}"/> -->
<gazebo reference="${wheel_name}">
    <fdir1>0 0 1</fdir1>

UPDATE : I actually did manage to get a physical model to "work" which is stable at 1/4th real time. However, the collision model means that the wheel looks like a ball, so any vehicle which uses it won't be able to get too close to any other object in the work (which is acceptable for my purposes right now). My robot uses three of these wheels and the following ODE parameters in the world:


Here is the omni wheel xacro (please excuse the comments left in for debugging):

<?xml version='1.0'?>

<robot xmlns:controller="&lt;a href=" http:="""" gazebo="" xmlschema="" #controller"="">" xmlns:interface="" xmlns:sensor="" xmlns:xacro="">

<property name="M_PI" value="3.1415926535897931"/> <property name="M_PI2" value="1.57079632679"/>

<xacro:macro name="subwheel" params="wheel_name wheel_radius subwheel_number n_subwheels cos_2pi_n_over_N sin_2pi_n_over_N cos_pi_over_N sin_pi_over_N subwheel_mass subwheel_joint_type">

<joint name="${wheel_name}_subwheel_${subwheel_number}_j" type="${subwheel_joint_type}">
    <origin xyz="${0.05*wheel_radius * cos_pi_over_N * cos_2pi_n_over_N} ${0.05*wheel_radius * cos_pi_over_N * sin_2pi_n_over_N} 0" rpy="0 0 ${2*M_PI*subwheel_number/n_subwheels}"/>
    <!-- <axis xyz="${-sin_2pi_n_over_N} ${cos_2pi_n_over_N} 0"/> -->
    <axis xyz="0 1 0"/>
    <parent link="${wheel_name}"/>
    <child link="${wheel_name}_subwheel_${subwheel_number}_l"/>

<!-- <gazebo reference="${wheel_name}_subwheel_${subwheel_number}_j">
</gazebo> -->

<link name="${wheel_name}_subwheel_${subwheel_number}_l">
        <mass value="${subwheel_mass}"/>
        <origin xyz="0 0 0" rpy="0 0 0"/>
        <inertia ixx="${2*subwheel_mass*(wheel_radius*wheel_radius*sin_pi_over_N*sin_pi_over_N)/5}" 
                 iyy="${2*subwheel_mass*(wheel_radius ...
2013-10-07 05:02:12 -0600 received badge  Taxonomist
2013-03-19 03:48:07 -0600 received badge  Popular Question (source)
2013-03-19 03:48:07 -0600 received badge  Notable Question (source)
2013-03-19 03:48:07 -0600 received badge  Famous Question (source)
2013-03-14 09:23:31 -0600 received badge  Famous Question (source)
2013-02-13 21:19:18 -0600 received badge  Notable Question (source)
2013-02-13 21:19:18 -0600 received badge  Popular Question (source)
2012-11-30 20:12:54 -0600 received badge  Self-Learner (source)
2012-11-30 20:02:57 -0600 received badge  Teacher (source)
2012-11-30 20:00:16 -0600 received badge  Student (source)
2012-11-29 19:11:00 -0600 answered a question The SetJointPositions function is not working in Gazebo 1.2

I did something similar in a c++ model plugin.

I have a private member variable of type

private: physics::JointController * j2_controller;

Which is initialized in the Load(physics::ModelPtr _parent, sdf::ElementPtr _sdf) function as follows

// Initialize the JointController with the model pointer
    this->j2_controller = new physics::JointController(_parent);

In, for instance, the OnUpdate() function, I have code that boils down to this:

double angle(0.0);
std::string j2name("j2name");    

However, my model is dynamic--I'm not sure if this would work to animate a static model. Hope that helps.

2012-11-29 19:02:31 -0600 asked a question Equivalent <transmission> or <actuator> tags in SDF (compared to URDF)

Does anyone know what Gazebo 1.2 does with the information in <transmission> or <actuator> tags? Perhaps using plugins? I know I can, for instance, use a model plugin to set one joint angle to be equivalent to another joint angle in the OnUpdate() function, but this seems to screw with the physics (and generally be an inelegant hack).

Has anyone had any luck loading the old pr2 gripper into new Gazebo? May be you can point me to an example of how to implement actuator or transmission models? I guess what I'm really interested in is a more elegant way to access the physics engine via a plugin to write my own transmissions like the ones used by pr2, or at least get theirs to work within a new Gazebo model.

2012-10-31 22:30:00 -0600 answered a question Visual Geometries/Meshes not Sticking to Link

I think I have found the problem. It actually (apparently) has nothing to do with the visualization. I certain friction parameter I passed was wrong enough to disrupt the physics engine (specifically, fdir1). I arrived at this conclusion by commenting out the .sdf file section-by-section. My best guess is that I caused something to become singular or nearly singular so all of the poses were reset. I'm now looking for a way to turn on any warnings or errors from the physics engine that might be suppressed.

Is there a way to toggle warnings from the different components of Gazebo?

If anyone else is having a similar problem, I suggest you first double check all the parameters you're passing to the physics engine.

2012-10-31 08:18:35 -0600 received badge  Editor (source)
2012-10-30 23:19:33 -0600 asked a question Visual Geometries/Meshes not Sticking to Link

Hi Everyone,

I have exported .STL meshes from Solidworks, and am trying to use them to visualize a mobile base. Some transforms are necessary in <model><link><pose> b/c the coordinate system in Solidworks is shifted. Everything is nicely aligned until I set <static>false</static>, and the all of my transforms get un-done! This only happens for the visual meshes. The collision objects that I have set up using simple geometries stay put relative to the correct reference frame of their links, but it's clear that the visual meshes end up back exactly where they would be if <pose> was all zeros. It's a pretty simple model with four links and three joints. Has anyone else had this issue? Is it due to the type of mesh that I'm using?

I'm attaching a screen shot of my static and dynamic models. I'm happy to share some code if you think it would help, but the mesh inclusion is verbatim to the examples (except using .stl and not .dae).

Thanks! Gwen

Screen Shot: Static on Left, Dynamic on Right

UPDATE: I still don't have a good answer as to why the mesh isn't sticking, but I did check that the same thing happens when I use the pioneer2ex's chassis.dae mesh instead of my *.STL mesh. However, I CANNOT recreate the problem in the mobile robot tutorial if I rotate the chassis by 90 degrees about the z-axis.

Screen Shot: Static on Left, Dynamic on Right, Pioneer Mesh w/ my Model

Screen Shot: Static on Left, Dynamic on Right, Pioneer Mesh w/ Tutorial Model

I have also checked that--in my model--if the visual mesh is replace by a simple geometry, the same thing happens: when static is set to false, none of the geometries stick to their respective links. They all just end up back at <pose>0.0 0.0 0.0 0.0 0.0 0.0</pose>. I should add that I'm not getting any warnings or errors in the terminal from Gazebo. With this additional information, has anyone else had a similar problem? Any solutions? Perhaps a pertinent environment variable for Gazebo is not properly set?

Thanks again! Gwen