Any hints to where or what to look for to figure the cause of these movements would be appreciated.
(The default darwins models do not seem to have this issue)
Some update from us. If we add a value of backlash 0.0058 to the HingeJointWithBacklash, the issue seems be reduced but not gone. Also the simulator complains about HingeJointWithBacklash (PROTO) > RotationalMotor: too low requested position: 0 < 0.01
Also using backlash 0.1 reduces the jumpiness, but it is still there.
I also notice there is a discrepancy between Documentation and Implementation of the HingeJointWithBacklash. The documentation here here claims it is by default 0.1. But this differs from the HingeJointWithBacklash.proto file.
Hi,
Your boundingObjects appear to be almost entirely boxes, is there a reason why you’re not using the Webots Box primitive? You might be adding unnecessary complexity using a mesh in this case. I quickly tried to replace those on the feet with normal Boxes and it seems to have an effect, I didn’t check further than that but might be worth a try.
Also, keep in mind that by not specifying the physics node at the Robot level, the default parameters are being applied (for instance, a mass of 1 is added there).
I wouldn’t worry about the position warning yet since as you mentioned you’re not actually controlling the robot, it could be violating the limits when it bounces. Just make sure the limits on your motors/hinges are set properly as described here. The relevant part is:
Finally, note that when both soft (minPosition and maxPosition (motor limits)) and hard limits (minStop and maxStop, see JointParameters) are activated, the range of the soft limits must be included in the range of the hard limits, such that minStop <= minPosition and maxStop >= maxPosition. Moreover a simulation instability can appear if position is exactly equal to one of the bounds defined by the minStop and maxStop fields at the simulation startup.
Concerning the backlash, to begin with I would try disabling it entirely (set it to 0) and isolate whether the problem comes from that or something else.
Also keep in mind that the timestep matters a lot when activating the backlash. If it’s too big, it could be provoking these sort of instabilities. I wouldn’t go above 8 [ms] for the backlash values you’re mentioning.
Thanks for pointing out the discrepancy in the documentation, I updated it.
I checked minStop and maxStop, but they aren’t set.
I tried backlash 0, which reduced the issue, but it was still there.
We replaced the STL collision boxes with the Box primitive. This solved the problem for us.
Even though I didn’t expect this to work, it does solve the problem for us.
