Gazebo Answers logo

Regarding the screen captures below. The system was running the 5step demo of the BDI walking (1/3 ms, 90 iters), and we captured the data. The first image shows a single step from touch down of left until after touchdown of right, which occurs between 557.6 and 557.8 seconds.

The second image shows a close up of the right foot touch down range. The position, both foot elevation and hip/knee joint data is smooth; the effort data is noisy as expected. My concern is with the force data from the force/torque sensor.

I'm curious about the initial spike (magenta) in r_foot force/z shown in upper left plot of the second (zoomed) image. This occurs after the left foot force has dropped to nearly zero (our robot is almost running!). After this right foot spike, the left foot force shooting up to almost twice the weight of single support, and then decays.

The second magenta spike seems to coincide with the actual touch down of the right foot. I can't make sense of the data between 557.5+0.16--> 0.19 in the second figure.

Is this a limitation of simulation physics engine?

Will this be cleaned up with next release?

Is this somehow expected behavior?

image description image description

Originally posted by dcconner on Gazebo Answers with karma: 298 on 2013-04-12

Post score: 0

Original comments

Comment by scpeters on 2013-04-12:
You say you're "curious about the initial spike (magenta) in r_foot force/z shown in upper right image." Do you mean the upper left image? It might be helpful if you annotate these plots with when you think touchdown/lift-off is happening and draw arrows to the data features that you find questionable.

Comment by dcconner on 2013-04-13:
fixed image reference in question. Looking at the zoomed image, the lower right plot shows feet height; the actual moment of contact and stance change occurs at 0.22 (557.5 + 0.22). This corresponds to the second magenta spike in the upper right plot of second image. The only thing I can think is that the first spike corresponds to the "toe" making contact before the foot is firmly in place, but I don't think these forces are at all realistic between 0.16 and 0.19 (+557.5)

Comment by scpeters on 2013-04-13:
I would guess that some part of the right foot strikes the ground at about 557.5 + 0.175 (could be toe or heel). The forces on the right foot then drops to zero, so it may have been a momentary strike. Which forces do you find unrealistic? The left foot or the right foot? If this is a repeatable event, I would try making a video. Turn the real-time factor down (update rate to 100 or so), so that the simulation goes in slow motion, then take a video with contacts turned on using recordmydesktop.

Comment by dcconner on 2013-04-14:
It will be a while before I can do the video. This is repeatable; I see this pattern on all steps of the BDI 5steps demo. I focused on one trasition, but it occurs with each step. It appears there is some minimal right foot contact around +0.16 (magenta line moves up slightly), followed by the left supporting force dropping to near zero for a few time steps. At this point, the robot is experiencing a significantly lower Fz than the weight of robot. This is followed by left force spiking

Comment by dcconner on 2013-04-14:
to almost 2x the nominal single support value. This force begins to decay, and a large transient spike on right foot is seen around +0.175. This right force value disappears, and the higher than expected left force continues to decay until the actual left/right support transition occurs at +0.22. So the force data from +0.16 to +0.20 does not seem correct to me. Can anyone confirm the behavior on their systems?

Comment by scpeters on 2013-04-14:
If you're concerned about the magnitude of the normal forces, I would also look at the vertical acceleration. The foot forces will only equal the weight of the robot if it's in a quasistatic equilibrium. If the robot is accelerating updwards or downwards, then the vertical forces at the feet will change accordingly.

Comment by dcconner on 2013-04-16:
I am pleased to note that this issue has disappeared with drcsim-2.4 update. Hopefully it stays away.


1 Answer 1


Gazebo Answers logo

I believe that this problem was addressed by Gazebo pull request #447, which was first released in Gazebo 1.6.2.

Originally posted by gerkey with karma: 1414 on 2013-04-16

This answer was ACCEPTED on the original site

Post score: 1


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.