Gazebo | Ignition | Community
Ask Your Question

arennuit's profile - activity

2018-07-27 14:15:43 -0600 received badge  Famous Question (source)
2016-06-29 09:21:53 -0600 received badge  Taxonomist
2015-10-28 04:30:37 -0600 received badge  Famous Question (source)
2015-07-02 08:00:23 -0600 received badge  Famous Question (source)
2015-06-22 19:17:40 -0600 received badge  Notable Question (source)
2015-06-07 22:20:20 -0600 received badge  Famous Question (source)
2015-03-14 10:01:18 -0600 received badge  Famous Question (source)
2014-12-18 05:36:28 -0600 received badge  Notable Question (source)
2014-12-17 16:50:41 -0600 received badge  Famous Question (source)
2014-12-05 07:48:56 -0600 received badge  Notable Question (source)
2014-12-05 07:48:56 -0600 received badge  Popular Question (source)
2014-10-31 16:34:39 -0600 received badge  Notable Question (source)
2014-10-31 16:34:39 -0600 received badge  Popular Question (source)
2014-10-29 15:10:44 -0600 received badge  Famous Question (source)
2014-10-09 04:20:02 -0600 received badge  Notable Question (source)
2014-10-08 06:15:59 -0600 received badge  Popular Question (source)
2014-10-08 06:07:50 -0600 received badge  Popular Question (source)
2014-10-08 01:04:27 -0600 commented question Mecanum wheels ok in one direction not the other in Gazebo

This is interesting, and indeed you are right, it appears the limit does not come from the simulation engine but from the possibility to change the frame of a link/joint without moving the link joint. Thanks for the reply!

2014-10-07 18:26:02 -0600 received badge  Popular Question (source)
2014-10-07 10:58:43 -0600 received badge  Notable Question (source)
2014-10-03 08:46:02 -0600 received badge  Notable Question (source)
2014-10-02 08:56:29 -0600 asked a question Bug in joint frame display

Hi,

I am working on a complex scene and realized something was wrong with the way the joints were displayed. Hence I made another super simple scene highlighting the problem (you can find it below).

On the below scene shown in the picture a joint is rotated 45° around Z and a box link is attached to it. The link is displayed correctly in the picture, but for some reason, the joint is displayed aligned with the world, and not rotated 45° as expected (note that the position of the joint frame is ok, only its rotation is wrong).

image description

Setup: gazebo 4.0 / indigo / trusty

See for yourself with the urdf:

<robot xmlns:xacro="&lt;a href=" http:="" www.ros.org="" wiki="" xacro"="">http://www.ros.org/wiki/xacro" name="lpc" >

  <!-- The chassis is an approximation of the nanotubes, the motors... everything but the polycarbonate sheet. -->
  <property name="chassis_sx" value="0.7874" />  <!-- 31" on plans -->
  <property name="chassis_sy" value="0.5334" />  <!-- 21" on plans -->
  <property name="chassis_sz" value="0.0762" />  <!-- 3" on plans -->

  <property name="wheel_radius" value="0.0758" /> <!-- dummy link - should be 0.001 -->


  <!-- /////////////////////////////////////////////////////////////////////////////////////// -->
  <!-- Scene definition. -->
  <!-- /////////////////////////////////////////////////////////////////////////////////////// -->
  <xacro:macro name="box_inertia" params="sizeX sizeY sizeZ mass *origin">
    <inertial>
      <mass value="${mass}" />
      <insert_block name="origin" />
      <inertia ixx="${mass / 12 * (sizeY * sizeY + sizeZ * sizeZ)}" ixy="0.0" ixz="0.0"
               iyy="${mass / 12 * (sizeX * sizeX + sizeZ * sizeZ)}" iyz="0.0"
               izz="${mass / 12 * (sizeX * sizeX + sizeY * sizeY)}" />
    </inertial>
  </xacro:macro>

  <!-- Chassis. -->
  <link name="chassis" >
    <visual>
      <geometry>
        <box size="${chassis_sx} ${chassis_sy} ${chassis_sz}" />
      </geometry>
      <origin xyz="0.0 0.0 ${wheel_radius}" rpy="0.0 0.0 0.0" />
    </visual>
    <collision>
      <geometry>
        <box size="${chassis_sx} ${chassis_sy} ${chassis_sz}" />
      </geometry>
      <origin xyz="0.0 0.0 ${wheel_radius}" rpy="0.0 0.0 0.0" />
    </collision>
    <xacro:box_inertia sizeX="${chassis_sx}" sizeY="${chassis_sy}" sizeZ="${chassis_sz}" mass="5.0">
      <origin xyz="0.0 0.0 ${wheel_radius}" rpy="0.0 0.0 0.0" />
    </xacro:box_inertia>
  </link>

  <joint name="dummy_joint" type="continuous">
    <parent link="chassis" />
    <child link = "dummyLink" />
    <origin xyz="0.3 0.0 0.3" rpy="0.0 0.0 0.7854" />
    <axis xyz="0.0 1.0 0.0" />
    <limit effort="100.0" velocity="100.0"/>
    <dynamics damping="0.0" friction="0.0"/>
  </joint>

  <link name="dummyLink" >
    <visual>
      <geometry>
        <box size="0.2 0.05 0.2" />
      </geometry>
      <origin xyz="0.0 0.0 0.0" rpy="0.0 0.0 0.0" />
    </visual>
    <collision>
      <geometry>
        <box size="0.2 0.05 0.2" />
      </geometry>
      <origin xyz="0.0 0.0 0.0" rpy="0.0 0.0 0.0" />
    </collision>
    <xacro:box_inertia sizeX="0.2" sizeY="0.05" sizeZ="0.2" mass="1.0">
      <origin xyz="0.0 0.0 0.0" rpy="0.0 0.0 0.0" />
    </xacro:box_inertia>
  </link>

</robot>

I had a look at the code for JointVisual::Load but everything looked fine in this file...

Does anyone confirm it is a bug? Should I open an issue?

Thanks,

Antoine.

2014-10-01 04:02:54 -0600 asked a question Joint::SetAxis() does not call JointVisual::Update()

Hi,

I was expecting that calling Joint::SetAxis() would call JointVisual::Update() under the hood but it does not seem to be the case. Is that expected?

The idea is to update the visual representation of a joint axis when its direction is updated at runtime.

Thanks,

Antoine.

2014-10-01 03:04:25 -0600 commented answer Change frame of a link/joint without moving the link joint

You are right indeed. I am a bit scared of the stability and performance of simulating a real mecanum wheel though but that may be worth a test. Will investigate this solution... Regards

2014-10-01 00:48:17 -0600 commented answer Gazebo4 installation along ROS-indigo

Thanks, that helps

2014-10-01 00:48:00 -0600 commented answer Gazebo4 installation along ROS-indigo

It sounds good to me, though I would add a word on the other packages available for gazebo4 (ros-$distro-gazebo4-ros-control and likes)... Thanks for your help!

2014-10-01 00:46:20 -0600 received badge  Popular Question (source)
2014-09-30 17:03:24 -0600 commented answer Change frame of a link/joint without moving the link joint

Aargh! We need this to simulate mecanum wheels... do you know if there exists (paid) gazebo support that could fast track the implementation of this feature? (issue created here).

2014-09-30 11:59:54 -0600 asked a question Change frame of a link/joint without moving the link joint

Hello,

Is there a way to change the frame of a link/joint at runtime? I am asking because I would like to change the axis of rotation of a joint at runtime (by editing the frame in which this axis is expressed).

Note: Entity::SetWorldPose() is not an option because it changes the position of the underlying link/joint and disturbs the momenta.

Kind regards,

Antoine.

2014-09-28 08:40:56 -0600 asked a question Gazebo4 installation along ROS-indigo

Hi all,

I have installed ROS-indigo (desktop full) and I wanted to install Gazebo 4 on top of it. From reading the instructions here I thought I would have to build from the sources (quote: " The way to go is to build them from source"). Then I started following the instructions and installed ros-$distro-gazebo4-ros-pkgs and ros-$distro-gazebo4-ros-control from the osrf repo and unexpectingly. Without any additional step, the gazebo version now being used is 4. From the install steps, I was expecting to have to build gazebo from the sources... Quote: "Use catkin workspaces to compile the rest of the software used from source". Is the behavior I observed expected?

Thanks,

Antoine.

2014-09-25 15:21:35 -0600 received badge  Student (source)
2014-09-25 12:25:54 -0600 asked a question Link::SetWorldPose() not behaving as expected

Dear all,

I am currently putting in place a simulation trick for mecanum wheels, as seens in V-Rep. This trick allows to simulate mecanum wheels stably and without the need to simulate real mecanum wheels (quite daunting numerically speaking because of the numerous contacts).

A single roller is attached to the wheel and its axis is reoriented at each step in a gazebo plugin to enforce the roller to be always aligned with the ground plane (otherwise the roller axis would turn due to the turn of its wheel parent).

The hierarchy goes like this:

  • mobile platform base link
    • wheel joint: continuous / revolute (its axis is actuated and is the normal axis of the wheel)
      • dummy wheel link
        • visual representation of the wheel (this is the mesh of the mecanum wheel)
        • roller joint: continuous / revolute (its axis is oriented at 45°)
          • roller link
            • collision geometry (this is a collision sphere)

This method is illustrated on the following video shot in VRep (see here). Note how the roller joints (in blue) remain aligned rather than rotating with the wheels (which they should normally do without the plugin, as the roller joint is a child of the wheel): this is the job of the plugin to realign the rollers at each step.

According to this hierarchy, the joint which needs to have its axis oriented at 45° at all time is the roller joint. In order to enforce this, a gazebo plugin is used and calls Link::SetWorldPose(). So basically we do not modify the axis coordinates with respect to the joint: what we do is reorient the joint itself using Link::SetWorldPose. The plugin works fine expect for one thing: I obtain the expected movement of the platform when I turn the wheels, but unfortunately the wheels do not visually look like they are rotating, see for yourself here.

Hence the following questions: I find it weird to have to call Link::SetWorldPose() on the roller link in order to modify the pose of the roller joint, is that the normal way to do? I could not find any other way... And what frame is actually modified when calling Link::SetWorldPose()? Is it the relative position of the input joint frame with respect to its parents (input joint frame = frame of the joint before rotation of the joint)? Basically I have the feeling that Link::SetWorldPose() somehow alters more than just a single frame...

Now because I am not too sure which frame is modified by Link::SetWorldPose(), I have tested Link::SetRelativePose() but my simulation "explodes" when I do that hence it is probably also not doing what I believe it does. Hence the same question for Link::SetRelativePose(): what frame is actually modified when calling Link::SetRelativePose()?

Am I using the right functions to reorient the roller joint at each step?

I am using ROS indigo and gazebo 2.2.

Thanks,

Antoine.

NOTE: obviously I have read the API doc 30 times before posting this question ;)

2014-09-24 02:56:14 -0600 commented question Mecanum wheels ok in one direction not the other in Gazebo

This does not make sense to me, I have tried everything obvious and nothing seems to improve the situation... Either I have missed something obvious or I am reaching the limits of ODE. I am thinking about switching to bullet now...

2014-09-24 02:34:36 -0600 received badge  Popular Question (source)
2014-09-22 15:59:59 -0600 commented question Mecanum wheels ok in one direction not the other in Gazebo

Hi Peters, I have just added other links for the xacro and cpp files here and here. And you can also access these same files from here. Merci ;)

2014-09-22 15:45:42 -0600 received badge  Editor (source)
2014-09-22 07:52:14 -0600 commented question Mecanum wheels ok in one direction not the other in Gazebo

After investigating, it looks like it could be related to the linear approximation of contact cones in ODE (cones are approximated by pyramids). e.g. http://answers.ros.org/question/9640/rotation-error-in-gazebo-simulation/. I have tried playing with fdir1 though this is does not improve thing... Is there a way to increase the number of sides to the contact pyramid? I could not find anything related...

2014-09-20 06:45:50 -0600 asked a question Mecanum wheels ok in one direction not the other in Gazebo

Hi all,

This looks like a problem of contacts simulation parameters... Let me give more details:

I am currently trying to emulate mecanum wheels using ros indigo and gazebo 2.2 thanks to a trick I found in the VREP implementation of the youbot (see here). They actually use the hierarchy shown below for a single wheel and update the direction of the axis of revolute joint 2 at each frame:

Hierarchy for a wheel:

  • mobile platform base link
    • continuous / revolute joint 1 (its axis is the axis of the wheel – or motor, this is the joint which is actuated)
      • visual representation of the wheel (this is the mesh of the mecanum wheel)
      • dummy collision and inertia
      • continuous / revolute joint 2 (its axis is oriented at 45°, along the direction of the contacting roller and crosses the COM of the wheel)
        • collision geometry (this is a collision sphere)

I implemented this hierarchy for each wheel (urdf file here or here) and coded a gazebo plugin which performs the axis alignment computation (plugin code here or here). The system turns out to work ok when moving in the principal direction of the mobile robot (all mecanum wheels turn in the same direction), but when attempting to move sideways (2 opposite mecanum wheels rotating in one direction the two others in the opposite direction), the mobile robot moves as expected for a few frames but then goes back and forth in a way which is not realistic. It looks like a problem with contacts so I played a bit with the mu, kp and kd values of the link in contact with the floor but that did not help.

I have put some videos illustrating the working case when going frontwards (video here) and the problematic case when going sideways (video here). The simulations are stepped by hand to better show the problem.

On the second video (problematic case), the torque applied to the wheels is constant during the whole course of the simulation, hence the mobile movement should be sideways in the up direction. But we observe the wheels accelerate / slide before the mobile platform changes direction back and forth (up and down on the screen). This is very unintuitive.

If I replace the mecanum wheels with normal wheels, all is as expected. The orientation of wheel axes realigned at each step look fine from the printfs.

I am not sure what to do and feel a bit lost... Anyone has an idea of what I could change to improve things?

Thanks,

Antoine.

------ UPDATE -------

The urdf and plugin files can alternatively also be found here and here. Or here.

Also, I have just tried lowering the mu value for the chassis and rollers (chassis_link_sdf_mu and roller_link_sdf_mu) to 0.2 rather than 1.0, as I read some posts saying it could help, but in my case it did not change much...

2014-09-12 23:56:40 -0600 asked a question Gazebo crashes (race condition?)

Hi all,

-- Question initially posted on ROS answers but I realized I should have posted it here --

I am currently using gazebo with a urdf of mine (under precise and hydro). It turns out to work well... once in every 5 or 6 sessions. With absolutely no change in the urdf or the config (I am repeatedly launching the same file from the same command line), I get repeated crashes and then once every 5 or 10 sessions (it varies) the simulation happens to work.

There are actually different error messages and which error message is displayed seems to be random depending on the session.

From the example error messages provided below, this problem could look like a race condition. Any idea of what's going on? Is this a known problem?

Thanks,

Antoine.

1st example error message

[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request:  153 (DRI2)
Minor opcode of failed request:  3 (DRI2CreateDrawable)
Resource id in failed request:  0x4a00002
Serial number of failed request:  29
Current serial number in output stream:  31
[Thread 0xaf9ffb40 (LWP 6304) exited]
[Thread 0xb17ffb40 (LWP 6295) exited]
[Thread 0xb0dffb40 (LWP 6296) exited]
[Thread 0xae7feb40 (LWP 6306) exited]
[Thread 0xadffdb40 (LWP 6307) exited]
gzserver: /usr/include/boost/thread/pthread/mutex.hpp:47: boost::mutex::~mutex(): Assertion `!pthread_mutex_destroy(&m)' failed.
[Thread 0xacffbb40 (LWP 6309) exited]
[Thread 0xaefffb40 (LWP 6305) exited]
[Thread 0xad7fcb40 (LWP 6308) exited]

Program received signal SIGABRT, Aborted.
0xb7fdd424 in __kernel_vsyscall ()
(gdb)

2nd example error message

[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request:  153 (DRI2)
Minor opcode of failed request:  3 (DRI2CreateDrawable)
Resource id in failed request:  0x4a00002
Serial number of failed request:  29
Current serial number in output stream:  31
[Thread 0xafbfeb40 (LWP 8328) exited]
[Thread 0xb17ffb40 (LWP 8318) exited]
[Thread 0xb0ffeb40 (LWP 8319) exited]
[Thread 0xad9fdb40 (LWP 8332) exited]
[Thread 0xae1feb40 (LWP 8331) exited]
[Thread 0xad1fcb40 (LWP 8333) exited]
[Thread 0xaf3fdb40 (LWP 8329) exited]
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >'
terminate called recursively
what():  boost::lock_error
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xac9fbb40 (LWP 8334)]
0xb7fdd424 in __kernel_vsyscall ()
(gdb)

3rd example error message

[ INFO] [1410583321.907129485]: Starting gazebo_ros_control plugin in namespace: /
[ INFO] [1410583321.908766555]: gazebo_ros_control plugin is waiting for model URDF in parameter [robot_description] on the ROS param server.
X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request:  153 (DRI2)
Minor opcode of failed request:  3 (DRI2CreateDrawable)
Resource id in failed request:  0x4e00002
Serial number of failed request:  29
Current serial number in output stream:  31
[spawn_gazebo_model-4] process has finished cleanly
log file: /home/arennuit/.ros/log/4abaa3e0-3b00-11e4-8318-0024d7bbc374/spawn_gazebo_model-4*.log
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl ...
(more)