Resetting robot using code weird behaviour

[HeChengHui]

Hi, I am building a programme that moves the robot back to the starting point if it reaches some undesired place.
I do so by calling a reset function:

def reset(self):
        MotorFrontLeftW.setVelocity(0)
        MotorBackLeftW.setVelocity(0)
        MotorFrontRightW.setVelocity(0)
        MotorBackRightW.setVelocity(0)
        MotorFrontLeftW.setPosition(float('inf'))
        MotorBackLeftW.setPosition(float('inf'))
        MotorFrontRightW.setPosition(float('inf'))
        MotorBackRightW.setPosition(float('inf'))
        robot_translateion_field.setSFVec3f(self.STARTING_POS)
        robot_rotation_field.setSFRotation(self.STARTING_ROT)
        robot_node.resetPhysics()

However, it will sometimes just implode(?) or collapse when moved to starting position.

Webots_demo.mp4

The Track node has no BoundingObject and only Floor node has a BoundingObject of a 1mx1m plane. Any idea on how not to let that happen?

[HeChengHui]

i think it may be something related to how the robot can somehow clip through bounding objects?

[ad-daniel]

Is STARTING_POS above ground or as you've shown in the second picture? Have you tried resetting slightly higher vertically?
If the starting position is already penetrating the ground it might indeed provoke these sort of explosions as the physics engine pushes the robot away (in this case too violently) in order to not break the constraint.

Also, does the same occur if you decrease the timestep significantly? It could be that due to the weight of the robot, 1 timestep after reset if finds itself penetrating the ground.

[HeChengHui]

@ad-daniel Thank you for your feedback.

I have tried setting translation such that the wheels are above and below the floor plane, and both cause the same reaction (setting above seems to have a much higher probability of it happening). I have also thought that it might be the weight of the robot so I made all the nodes with physics to have mass -1.
Example:

physics Physics {
      mass -1
      centerOfMass [ 0.007500 0.000000 -0.010000 ]
    }

But doing so doesn't seem to resolve the situation. I can upload the proto file if you would like to take a look.

I have not tried the timestep method so I would give it a try first.

[HeChengHui]

Thank you for your help!

I will give it a try and change my environment.
I am using a timestep of 40 to get 25fps on the camera.

[ad-daniel]

Controller and world can have different timesteps (as long as they are multiples of each other). So you can have a low timestep (in worldInfo), and the while loop in your controller (while robot.step(timestep) != -1) you can set a different value for it.

[HeChengHui]

Hmm I see.
But is there any benefits from using a small global timestep?
And why would it be not advisable to use a timestep like 40?

[ad-daniel]

When the timestep is large, it's easier for the wheels to break the constraints of the ground (i.e it sinks into it), so although part of this penetration gets corrected the following timesteps, when the next clock tick comes, it will happen again and again. This isn't ideal, first because it's not very realistic and because it can destabilize the system as it attempts to correct the penetration over and over (especially if you don't make the contact properties between the wheel and the ground softer (increasing softCFM and softERP). If they are hard, it will react more violently to these violations). By lowering the timestep, you're diminishing this phenomena. Of course it also makes the simulation slower, so you'll need to balance the two things. I would drop it at least to 10 or 20.

[HeChengHui]

Thank you for the explanation, I will try out a timestep of 20 next.