Home | Tutorials | Wiki | Issues
Ask Your Question

Modeling Omni Wheels

asked 2014-02-26 10:42:26 -0500

Gwen gravatar image

updated 2014-03-02 15:01:20 -0500

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:="" playerstage.sourceforge.net="" gazebo="" xmlschema="" #controller"="">http://playerstage.sourceforge.net/gazebo/xmlschema/#controller" xmlns:interface="http://playerstage.sourceforge.net/gazebo/xmlschema/#interface" xmlns:sensor="http://playerstage.sourceforge.net/gazebo/xmlschema/#sensor" xmlns:xacro="http://playerstage.sourceforge.net/gazebo/xmlschema/#interface">

<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 ...
edit retag flag offensive close merge delete


This question is on a related topic: http://answers.gazebosim.org/question/5476/parameters-for-a-skid-steeringsimulated-tracked/ ...seems like something is up (or at least misunderstood) with the <fdir1> tag.

Gwen gravatar imageGwen ( 2014-02-27 11:25:12 -0500 )edit

Hi Gwen. Did you ever get this to work correctly with normal time settings? (you said you used 1/4th real time). Thanks

pmolina gravatar imagepmolina ( 2015-01-16 08:41:43 -0500 )edit

Hello, I'm having a similar problem, but as far as I've been able to understand, fdir1 is the vector that defines the direction of mu1, which is the "principal contact direction" (check it here: http://gazebosim.org/tutorials/?tut=ros_urdf#Links)

SergioMP gravatar imageSergioMP ( 2015-10-06 12:04:05 -0500 )edit

Have you tried checking the generated .sdf file? rosrun xacro xacro --inorder robot.xacro > robot.urdf gz sdf -p robot.urdf > robot.sdf Because for me the friction parameters are not generated at all. It looks like this: <friction> <ode/> </friction>

SorinV gravatar imageSorinV ( 2017-06-07 02:19:37 -0500 )edit

Hey Gwen can you share your whole omni wheel project somewhere? I would like to try and test it.

markus gravatar imagemarkus ( 2017-12-04 03:11:41 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2019-02-07 17:24:31 -0500

Check out GuiRitter'shttps://github.com/GuiRitter/OpenBase repo.

His omni-wheel xacro model works pretty well. I just successfully ran the demo in Gazebo.

Note: This is an old question, but it still pops up when you google "Gazebo omniwheel".

edit flag offensive delete link more
Login/Signup to Answer

Question Tools



Asked: 2014-02-26 10:42:26 -0500

Seen: 4,598 times

Last updated: Feb 07