Atlas falls when stepping with libAtlasSimInterface3.so.3.0.0

osrf-migration commented 9 years ago

Original report (archived issue) by GoRobotGo (Bitbucket: GoRobotGo).

The original report had attachments: test_fall.cpp, test_fall_rotated.cpp, test_up.cpp, test_up.mp4, test_up.world, bouncyfoot.mp4, bouncyfoot2.mp4, step.mp4, bouncy_foot.cpp, bouncy_foot.world, bouncy_toe.cpp

The new libAtlasSimInterface is installed per: http://gazebosim.org/tutorials?tut=drcsim_install

It falls over when attempting to use the step behavior using a v3 or a v4 robot. v5 falls over on startup. Is the step behavior expected to work with the new libAtlasSimInterface? What is expected to work and not work (with what robot versions) with the new libAtlasSimInterface3?

This is on the current pre-release (4.2.0)

osrf-migration commented 9 years ago

Original comment by Mathew DeDonato (Bitbucket: mdedonato NA).

I had the same issue with the V5 Model. Is there a way to confirm which library is running, to verify that the libAtlasSimInterface was installed correctly?

osrf-migration commented 9 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

We expect BDI to release new libraries sometime this week. In the mean time, you can try using DART. It's not an optimal solution, but it may get you going.

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

BDI step is still broken with the Jan 3 pre-release along with BDI 3.0.1. It generally appears to try lifting the foot too high and then falls over.

osrf-migration commented 9 years ago

Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033).

How are you sending the step commands?

BDI advised us to use a swing height of 0.1 and we've recently made the change in our keyboard_teleop.py script (this value is passed to AtlasPlugin and used by AtlasBehaviorWalkParams) and the robot walks ok.

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

I was able to get it to take a few steps using BDI step, but there still appear to be some additional issues that cause it to fall. One of them is a feature request, a couple of the others are bugs that I am trying to put together test cases for.

The swing height was defaulted to 0.3 for the simulator in our code as well. I changed that to pass along along a more reasonable value and that helped. The ode solver iterations change to 100 helped as well. Getting closer!

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

Iters actually needs to be 200 for a number of step cases. Attached is a case (robot_fall.cpp) that fails at iters 100, but works at iters 200 (as atlas.world is set to). If you have existing worlds, you need to go through them and manually change the iters/sor for step to work. Interestingly, rotating the robot 90 degrees (yaw = 1.514) and using a rotated step set (robot_fall_rotated.cpp) works at iters=100.

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

set attachment to "test_fall_rotated.cpp"

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

A critical test case is that step can't step up onto a cinder block. Even with iters=1000 it still falls. Attached is test_up.world, test_up.cpp and test_up.mp4.

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

set attachment to "test_up.world"

osrf-migration commented 9 years ago

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

Just looking at the video, it looks like the right foot touches the cinder block on the way up. Can you check if eliminating contact between right foot and the cinder block prevents the robot from tipping over (i.e. by shift the cinder block to the left half way)?

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

I did some further experiments with it and here are my observations:

1. Moving the block out of the way of the right foot does allow the robot to stay up.
1. The collision model is larger than the visual model for the front of the foot - visually there is no collision, but the rectangular collision box does impact the block, the collision model should better match the foot
1. The inputs to AtlasBehaviorStepData.msg don't behave the same as on the real robot - a value of 0.15 lifts the foot 15cm above the previous foot (this matches), but the value of zero for the second (right foot) should lift the right foot up to the same height as the left foot. This does not match. This is assuming you are simulating the relative step mode. Going up steps with both feet on every step would look like: 0.15, 0, 0.15, 0, 0.15, 0 (for the z values)
1. It is possible by carefully moving the cinder block and changing the second step to have a z of 0.15 to get both feet up, but it requires much more precision than on the real robot. In particular, the toe must be further back from the cinder block and the heel must be further on the cinder block than with the real robot.
1. If even a small part of the heel is not on the block the foot goes unstable and falls off. See bouncyfoot.mp4

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

set attachment to "bouncyfoot.mp4"

osrf-migration commented 9 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

To summarize the remaining work to fix this issue involves:

Fix simple collision shape on the feet so that the toe does not catch when stepping.
Fix AtlasBehaviorStep so that simulation matches the real robot. If I understand the problem correctly, the current Atlas sim interface will not lift the right foot to match the height of the left foot when swing_height is set to zero.

osrf-migration commented 9 years ago

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

regarding

5. If even a small part of the heel is not on the block the foot goes unstable and falls off. See bouncyfoot.mp4

To see if collision detection is returning right contact normals, can you replay while enabling contact visuals and transparency? Thanks.

osrf-migration commented 9 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

See pull request #516 for foot collisions fix.

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

I don't think issue 2 has to do with swing_height. I think that the z height may be modified before it is passed to the bdi controller or else the bdi simulated controller is different than the robot bdi controller. If the first step has a z value of 0.15 and the second step has a z value of 0 the expected behavior is that the first step will go up 0.15m relative to the start and the second step will be at 0m relative to the first step (0.15m). Does that better explain it? Is the z value modified before it is passed to the bdi simulated controller?

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

I think there is a third issue having to do with the bouncy foot. I have attached the requested video.

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

set attachment to "bouncyfoot2.mp4"

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

If it would help, I would be happy to do an audio/video conference to discuss or work through this issue.

osrf-migration commented 9 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

Just checked, we don't modify the z value before passing it to the BDI controller.

osrf-migration commented 9 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

set attachment to "step.mp4"

Using keyboard_teleop with the following parameters:

step height: 0.15
swing height: 0.2
forward stride length: 0.35

The above video shows my attempt at reproducing the bouncy foot problem. This is using Atlas v5 with libAtlasSimInterface.so.3.0.2 and the drcsim_4.2 branch .

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

I have attached the files I use to reproduce the bouncy foot problem. I tried using the keyboard_teleop, but it only takes a single step when I use the "I" key for BDI step. How were you able to get it to take 2 steps in a row? In one window I do: roslaunch drcsim_gazebo bouncy_foot.launch model_args:="_v4" hand_suffix:="_robotiq_hands" In another window I do: ./bouncy_foot

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

set attachment to "bouncy_foot.world"

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

I guess the simulated bdi controller works differently than the bdi controller on the robot. I can work around that in my code by integrating / summing the relative heights before sending them to the simulator. That should resolve that portion of the problem.

osrf-migration commented 9 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

I hacked the keyboard teleop

#!c++

diff -r 51add9578761acd8751d64adf9a4cd664ff958c5 drcsim_gazebo/scripts/keyboard_teleop.py
--- a/drcsim_gazebo/scripts/keyboard_teleop.py  Tue Jan 13 09:06:25 2015 -0800
+++ b/drcsim_gazebo/scripts/keyboard_teleop.py  Tue Jan 13 12:50:50 2015 -0800
@@ -63,6 +63,8 @@
               "Swing Height":{"value":0.1, "min":0, "max":1, "type":"float"}}

     def init(self):
+        self.static_count = 0
+
         # Saves terminal settings
         self.settings = termios.tcgetattr(sys.stdin)

@@ -174,21 +176,24 @@
         self.is_static = True
         steps = self.build_steps(forward, lateral, turn)

+        idx = self.static_count % 2
+
         # step needs index to be 1
-        steps[0].step_index = 1
-        steps[0].swing_height = 0.05
+        steps[idx].step_index = 1
+        steps[idx].swing_height = 0.05

         # 0 for full BDI control, 255 for PID control
         k_effort =  [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
           0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

         stand_goal = WalkDemoGoal(Header(), WalkDemoGoal.STEP, None, \
-              AtlasBehaviorStepParams(steps[0], False), AtlasBehaviorStandParams(), \
+              AtlasBehaviorStepParams(steps[idx], False), AtlasBehaviorStandParams(), \
               AtlasBehaviorManipulateParams(),  k_effort )

         self.client.send_goal(stand_goal)
         # self.client.wait_for_result()

+        self.static_count = self.static_count + 1
         rospy.sleep(0.3)
         # for step in steps:
         #     step.step_index = 1

I'm trying out your example code now.

osrf-migration commented 9 years ago

Original comment by Bill Blank (Bitbucket: BillBlank).

I was successfully able to command the robot to step up three 0.1m rise stairs using both absolute and relative step heights. I also do not see any bouncy feet.

It looks like another problem I did see was addressed (pull request #516) above...that is, the collision box for the foot is tall compared to the actual foot geometry, making it easy for the robot to "stub" this top part of the collision box as its foot attempts to reach lift height.

It's not a bad idea to leave a little cushion between the front of the foot and the stair riser to allow for small errors in inverse kinematics...no one wants the foot to contact the riser unintentionally as it lifts pass the riser.

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

Nate - using your modified keyboard_teleop.py with the parameters you specify and bouncy_foot.world reproduces the problem. I was able to reproduce the problem over the range from 0.33-0.36 for the step size.

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

There is a similar issue when the toe hangs over the edge of the block. I have attached bouncy_toe.cpp to demonstrate (works with bouncy_foot.world).

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

set attachment to "bouncy_toe.cpp"

osrf-migration commented 9 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

What version of Gazebo are you using?

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

Gazebo 4.1.0 DRCSim pre-release (I believe 4.2.3), BDI 3.0.2

Note - I saw the problem using bouncy_foot.world, I assume you were using test_up.world for your video.

osrf-migration commented 9 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

Ok. I'll make another prerelease of drcsim tob make sure we are on the same page. My video was made using

#!c++

roslaunch drcsim_gazebo atlas.launch model_args:="_v5"

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

I see the same behavior on v4 & v5: roslaunch drcsim_gazebo bouncy_foot.launch model_args:="_v5" hand_suffix:="_robotiq_hands" teleop with the 0.35 / 0.15 / 0.2 shows the bouncy foot & fall.

A question - are you using DART or the default physics (ODE I believe)?

Just to be thorough - I tried with no hands and saw the same behavior: roslaunch drcsim_gazebo bouncy_foot.launch model_args:="_v5"

osrf-migration commented 9 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

I'm using ODE, and so far I can't reproduce the problem. Still digging.

osrf-migration commented 9 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

changed priority from "major" to "blocker"

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

I verified the issue was present on a second computer to make sure it wasn't a computer specific issue. Maybe a library or configuration issue? pldd on gzserver:

#!c++

30654:  /usr/bin/gzserver-4.1.0
linux-vdso.so.1
/usr/lib/x86_64-linux-gnu/libgazebo_common.so.4
/usr/lib/x86_64-linux-gnu/libgazebo_util.so.4
/usr/lib/x86_64-linux-gnu/libgazebo_transport.so.4
/usr/lib/x86_64-linux-gnu/libgazebo_physics.so.4
/usr/lib/x86_64-linux-gnu/libgazebo_sensors.so.4
/usr/lib/x86_64-linux-gnu/libgazebo_msgs.so.4
/lib/x86_64-linux-gnu/libpthread.so.0
/lib/x86_64-linux-gnu/libdl.so.2
/usr/lib/libprotobuf.so.7
/usr/lib/x86_64-linux-gnu/libgazebo_math.so.4
/usr/lib/libtbb.so.2
/usr/lib/x86_64-linux-gnu/libsdformat.so.2
/usr/lib/libboost_thread.so.1.46.1
/usr/lib/libboost_system.so.1.46.1
/usr/lib/libboost_program_options.so.1.46.1
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
/lib/x86_64-linux-gnu/libgcc_s.so.1
/lib/x86_64-linux-gnu/libc.so.6
/usr/lib/libboost_filesystem.so.1.46.1
/usr/lib/libboost_iostreams.so.1.46.1
/usr/lib/libfreeimage.so.3
/usr/lib/libtinyxml.so.2.6.2
/usr/lib/x86_64-linux-gnu/libavcodec.so.53
/usr/lib/x86_64-linux-gnu/libavformat.so.53
/usr/lib/x86_64-linux-gnu/libavutil.so.51
/usr/lib/x86_64-linux-gnu/libcurl.so.4
/usr/lib/x86_64-linux-gnu/libswscale.so.2
/usr/lib/libtar.so.0
/lib/x86_64-linux-gnu/librt.so.1
/lib/x86_64-linux-gnu/libm.so.6
/usr/lib/x86_64-linux-gnu/libgazebo_physics_ode.so.4
/usr/lib/x86_64-linux-gnu/libgazebo_physics_bullet.so.4
/usr/lib/x86_64-linux-gnu/libgazebo_physics_simbody.so.4
/usr/lib/libboost_regex.so.1.46.1
/usr/lib/x86_64-linux-gnu/libgazebo_rendering.so.4
/usr/lib/x86_64-linux-gnu/libOgreMain.so.1.7.4
/lib64/ld-linux-x86-64.so.2
/lib/x86_64-linux-gnu/libz.so.1
/lib/x86_64-linux-gnu/libbz2.so.1.0
/usr/lib/x86_64-linux-gnu/libjpeg.so.8
/usr/lib/x86_64-linux-gnu/libmng.so.1
/usr/lib/libopenjpeg.so.2
/usr/lib/libIlmImf.so.6
/usr/lib/libHalf.so.6
/usr/lib/libIex.so.6
/usr/lib/libraw.so.5
/lib/x86_64-linux-gnu/libpng12.so.0
/usr/lib/x86_64-linux-gnu/libgomp.so.1
/usr/lib/libvpx.so.1
/usr/lib/x86_64-linux-gnu/libvorbisenc.so.2
/usr/lib/x86_64-linux-gnu/libvorbis.so.0
/usr/lib/x86_64-linux-gnu/libtheoraenc.so.1
/usr/lib/x86_64-linux-gnu/libtheoradec.so.1
/usr/lib/x86_64-linux-gnu/libspeex.so.1
/usr/lib/libschroedinger-1.0.so.0
/usr/lib/libgsm.so.1
/usr/lib/x86_64-linux-gnu/libva.so.1
/usr/lib/x86_64-linux-gnu/libidn.so.11
/usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
/usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
/usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
/lib/x86_64-linux-gnu/libssl.so.1.0.0
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
/usr/lib/x86_64-linux-gnu/librtmp.so.0
/usr/lib/x86_64-linux-gnu/libgazebo_ode.so.4
/usr/lib/libBulletDynamics.so.2.82
/usr/lib/libBulletCollision.so.2.82
/usr/lib/libLinearMath.so.2.82
/usr/lib/x86_64-linux-gnu/libSimTKsimbody.so.3.4
/usr/lib/x86_64-linux-gnu/libSimTKmath.so.3.4
/usr/lib/x86_64-linux-gnu/libSimTKcommon.so.3.4
/usr/lib/libicuuc.so.48
/usr/lib/libicui18n.so.48
/usr/lib/x86_64-linux-gnu/libgazebo_skyx.so.4
/usr/lib/x86_64-linux-gnu/libgazebo_selection_buffer.so.4
/usr/lib/x86_64-linux-gnu/libOgreRTShaderSystem.so.1.7.4
/usr/lib/x86_64-linux-gnu/libOgreTerrain.so.1.7.4
/usr/lib/x86_64-linux-gnu/libOgrePaging.so.1.7.4
/usr/lib/nvidia-331/libGL.so.1
/usr/lib/x86_64-linux-gnu/libX11.so.6
/usr/lib/libCEGUIBase-0.7.5.so
/usr/lib/libCEGUIOgreRenderer-0.7.5.so
/usr/lib/x86_64-linux-gnu/libfreetype.so.6
/usr/lib/x86_64-linux-gnu/libXt.so.6
/usr/lib/x86_64-linux-gnu/libXaw.so.7
/usr/lib/libzzip-0.so.13
/usr/lib/x86_64-linux-gnu/liblcms.so.1
/usr/lib/libImath.so.6
/usr/lib/libIlmThread.so.6
/usr/lib/x86_64-linux-gnu/libjasper.so.1
/usr/lib/x86_64-linux-gnu/liblcms2.so.2
/usr/lib/x86_64-linux-gnu/libogg.so.0
/usr/lib/x86_64-linux-gnu/liborc-0.4.so.0
/lib/x86_64-linux-gnu/libresolv.so.2
/usr/lib/x86_64-linux-gnu/libsasl2.so.2
/usr/lib/x86_64-linux-gnu/libgssapi.so.3
/usr/lib/x86_64-linux-gnu/libgnutls.so.26
/lib/x86_64-linux-gnu/libgcrypt.so.11
/usr/lib/x86_64-linux-gnu/libkrb5.so.3
/usr/lib/x86_64-linux-gnu/libk5crypto.so.3
/lib/x86_64-linux-gnu/libcom_err.so.2
/usr/lib/x86_64-linux-gnu/libkrb5support.so.0
/usr/lib/x86_64-linux-gnu/libgazebo_opcode.so.4
/usr/lib/x86_64-linux-gnu/libgazebo_opende_ou.so.4
/usr/lib/x86_64-linux-gnu/libgazebo_ccd.so.4
/usr/lib/liblapack.so.3gf
/usr/lib/libblas.so.3gf
/usr/lib/libicudata.so.48
/usr/lib/nvidia-331/tls/libnvidia-tls.so.331.113
/usr/lib/nvidia-331/libnvidia-glcore.so.331.113
/usr/lib/x86_64-linux-gnu/libXext.so.6
/usr/lib/x86_64-linux-gnu/libxcb.so.1
/lib/x86_64-linux-gnu/libpcre.so.3
/usr/lib/x86_64-linux-gnu/libSM.so.6
/usr/lib/x86_64-linux-gnu/libICE.so.6
/usr/lib/x86_64-linux-gnu/libXmu.so.6
/usr/lib/x86_64-linux-gnu/libXpm.so.4
/usr/lib/x86_64-linux-gnu/libheimntlm.so.0
/usr/lib/x86_64-linux-gnu/libkrb5.so.26
/usr/lib/x86_64-linux-gnu/libasn1.so.8
/usr/lib/x86_64-linux-gnu/libhcrypto.so.4
/usr/lib/x86_64-linux-gnu/libroken.so.18
/usr/lib/x86_64-linux-gnu/libtasn1.so.3
/usr/lib/x86_64-linux-gnu/libp11-kit.so.0
/lib/x86_64-linux-gnu/libgpg-error.so.0
/lib/x86_64-linux-gnu/libkeyutils.so.1
/usr/lib/x86_64-linux-gnu/libgfortran.so.3
/usr/lib/x86_64-linux-gnu/libXau.so.6
/usr/lib/x86_64-linux-gnu/libXdmcp.so.6
/lib/x86_64-linux-gnu/libuuid.so.1
/usr/lib/x86_64-linux-gnu/libwind.so.0
/usr/lib/x86_64-linux-gnu/libheimbase.so.1
/usr/lib/x86_64-linux-gnu/libhx509.so.5
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0
/lib/x86_64-linux-gnu/libcrypt.so.1
/usr/lib/x86_64-linux-gnu/libquadmath.so.0
/opt/ros/hydro/lib/libgazebo_ros_api_plugin.so
/opt/ros/hydro/lib/libroslib.so
/opt/ros/hydro/lib/libroscpp.so
/opt/ros/hydro/lib/librosconsole.so
/opt/ros/hydro/lib/libdynamic_reconfigure_config_init_mutex.so
/opt/ros/hydro/lib/libroscpp_serialization.so
/opt/ros/hydro/lib/librostime.so
/opt/ros/hydro/lib/librospack.so
/opt/ros/hydro/lib/libxmlrpcpp.so
/opt/ros/hydro/lib/libcpp_common.so
/usr/lib/libboost_signals.so.1.46.1
/opt/ros/hydro/lib/librosconsole_log4cxx.so
/opt/ros/hydro/lib/librosconsole_backend_interface.so
/usr/lib/liblog4cxx.so.10
/usr/lib/libpython2.7.so.1.0
/opt/ros/hydro/lib/libconsole_bridge.so
/usr/lib/libaprutil-1.so.0
/usr/lib/libapr-1.so.0
/lib/x86_64-linux-gnu/libutil.so.1
/lib/x86_64-linux-gnu/libexpat.so.1
/lib/x86_64-linux-gnu/libnss_files.so.2
/usr/lib/x86_64-linux-gnu/OGRE-1.7.4/RenderSystem_GL.so
/usr/lib/x86_64-linux-gnu/libGLU.so.1
/usr/lib/x86_64-linux-gnu/libXrandr.so.2
/usr/lib/x86_64-linux-gnu/libXrender.so.1
/usr/lib/x86_64-linux-gnu/OGRE-1.7.4/Plugin_ParticleFX.so
/usr/lib/x86_64-linux-gnu/OGRE-1.7.4/Plugin_BSPSceneManager.so
/usr/lib/x86_64-linux-gnu/OGRE-1.7.4/Plugin_OctreeSceneManager.so
/usr/lib/libtbbmalloc.so.2
/opt/ros/hydro/lib/drcsim_gazebo_ros_plugins/plugins/libVRCPlugin.so
/opt/ros/hydro/lib/drcsim_gazebo_ros_plugins/plugins/libVRCScoringPlugin.so
/opt/ros/hydro/lib/libgazebo_ros_camera.so
/opt/ros/hydro/lib/libgazebo_ros_camera_utils.so
/usr/lib/x86_64-linux-gnu/gazebo-4.1/plugins/libCameraPlugin.so
/opt/ros/hydro/lib/libtf.so
/opt/ros/hydro/lib/libimage_transport.so
/opt/ros/hydro/lib/libcamera_info_manager.so
/opt/ros/hydro/lib/libtf2_ros.so
/opt/ros/hydro/lib/libtf2.so
/opt/ros/hydro/lib/libmessage_filters.so
/opt/ros/hydro/lib/libclass_loader.so
/opt/ros/hydro/lib/libcamera_calibration_parsers.so
/opt/ros/hydro/lib/libactionlib.so
/usr/lib/libPocoFoundation.so.9
/usr/lib/libyaml-cpp.so.0.2
/lib/x86_64-linux-gnu/libnss_compat.so.2
/lib/x86_64-linux-gnu/libnsl.so.1
/lib/x86_64-linux-gnu/libnss_nis.so.2
/opt/ros/hydro/lib/libgazebo_ros_multicamera.so
/opt/ros/hydro/lib/libMultiCameraPlugin.so
/opt/ros/hydro/lib//libcompressed_depth_image_transport.so
/opt/ros/hydro/lib/libcv_bridge.so
/opt/ros/hydro/lib/libopencv_highgui.so.2.4
/opt/ros/hydro/lib/libopencv_core.so.2.4
/opt/ros/hydro/lib/libopencv_imgproc.so.2.4
/usr/lib/x86_64-linux-gnu/libtiff.so.4
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
/lib/x86_64-linux-gnu/libglib-2.0.so.0
/usr/lib/x86_64-linux-gnu/libv4l1.so.0
/usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0
/usr/lib/x86_64-linux-gnu/libXfixes.so.3
/usr/lib/x86_64-linux-gnu/libatk-1.0.so.0
/usr/lib/x86_64-linux-gnu/libcairo.so.2
/usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
/usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0
/usr/lib/x86_64-linux-gnu/libpango-1.0.so.0
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1
/usr/lib/x86_64-linux-gnu/libXinerama.so.1
/usr/lib/x86_64-linux-gnu/libXi.so.6
/usr/lib/x86_64-linux-gnu/libXcursor.so.1
/usr/lib/x86_64-linux-gnu/libXcomposite.so.1
/usr/lib/x86_64-linux-gnu/libXdamage.so.1
/usr/lib/x86_64-linux-gnu/libffi.so.6
/usr/lib/x86_64-linux-gnu/libv4l2.so.0
/usr/lib/x86_64-linux-gnu/libpixman-1.so.0
/usr/lib/x86_64-linux-gnu/libxcb-shm.so.0
/usr/lib/x86_64-linux-gnu/libxcb-render.so.0
/usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0
/lib/x86_64-linux-gnu/libselinux.so.1
/usr/lib/x86_64-linux-gnu/libv4lconvert.so.0
/opt/ros/hydro/lib/libgazebo_ros_gpu_laser.so
/usr/lib/x86_64-linux-gnu/gazebo-4.1/plugins/libGpuRayPlugin.so
/opt/ros/hydro/lib//libcompressed_image_transport.so
/opt/ros/hydro/lib/drcsim_gazebo_ros_plugins/plugins/libRobotiqHandPlugin.so
/opt/ros/hydro/lib/drcsim_gazebo_ros_plugins/plugins/libAtlasV4Plugin.so
/opt/ros/hydro/lib/libAtlasSimInterface3.so.3.0.2
/opt/ros/hydro/lib//libimage_transport_plugins.so
/opt/ros/hydro/lib//libtheora_image_transport.so
/opt/ros/hydro/lib/libgazebo_ros_joint_pose_trajectory.so
/opt/ros/hydro/lib/libgazebo_ros_p3d.so
/opt/ros/hydro/lib/libgazebo_ros_force.so
/opt/ros/hydro/lib/drcsim_gazebo_ros_plugins/plugins/libMultiSenseSLPlugin.so

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

The robot start position relative to the cinder block was noticeably different in 4.2.5 relative to 4.2.4. Once that was adjusted for both the bouncy foot and the bouncy toe issue are mostly gone in 4.2.5. There is some minor foot slippage and rotation, but it is maybe a tenth of what was present in 4.2.4 and no longer causes the robot to fall. The change to the collision model in atlas_v4_simple_shapes.urdf is what resolved the issue. Changing only the collision model, the bouncy foot & toe issues show up in 4.2.5. But, with the new collision model both are resolved in 4.2.5.

osrf-migration commented 9 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

Is this issue resolved now?

osrf-migration commented 9 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

Yes, I would say this issue is resolved.

osrf-migration commented 9 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

changed state from "new" to "resolved"

osrf / drcsim

Atlas falls when stepping with libAtlasSimInterface3.so.3.0.0 #457