Moving the robot in the bed bath task

[rajas1310]

Hi,
I was trying to rotate the robot base in the Bed Bath environment using the functions TurnLeft(angle,speed) and TurnRight(angle,speed).
When I input the angle as 180, the Stretch 3 turns only by 90 degrees.
When I input the angle as 90, the Stretch 3 turns approximately by 45 degrees.
When I input the angle as 270, the Stretch 3 turns by more than 90 degrees and makes very jerky movements ultimately falling down.

The speed parameter did not make any difference as per my observation.

Is there something that I have missed in understanding what those (angle and speed) arguments do? Or is it a bug?

PFA the video for Case-1 (angle=180, speed=60) and Case-2 (angle=270, speed=60)
rotation-180-60.webm
rotation-270-60.webm

[YoruCathy]

We've updated the scripts in the newest commit 0953f70
Could you pull it and give it a try?

[thisjustin123]

Thinking about it more, I think this bug is happening due to variable performance of everyone's machines. I'm fairly certain it's caused by the fact that Unity may run slower/quicker depending on framerate, meaning the simulation can literally get slowed down vs. real time with lower framerates.

I'm not exactly sure why this is happening but I'll look into a fix.

[DanielTakeshi]

@thisjustin123 Thanks for the comment. Do you have any empirical results or minimum working example code (ideally run on separate machines) to demonstrate?

[martinschonger]

Hi Justin, thanks for looking into this.

You are saying here that you are observing the right turn cause the Y-angle to rotate, is that correct?

Yes. I can see you fixed that in the unit tests.

I think this bug is happening due to variable performance of everyone's machines. I'm fairly certain it's caused by the fact that Unity may run slower/quicker depending on framerate, meaning the simulation can literally get slowed down vs. real time with lower framerates.

I tested on a more powerful machine and there the left and right turn behavior is closer to what I would expect. This is interesting since at least the physics simulation should be framerate-independent according to https://docs.unity3d.com/Manual/ExecutionOrder.html. Still, I guess this discrepancy means that a controller designed on some machine would behave differently on the evaluation platform, right?

[DanielTakeshi]

@martinschonger Thanks for checking. But indeed the last point you bring up is critical. How may we tell if our solution(s) are going to work well if it could be dependent on something like the machine it's evaluated on? We would need to know exactly the machine specs, and if we don't have that machine, presumably we're out of luck?

[thisjustin123]

I should be able to change the logic in Unity to make it framerate independent. Currently, it runs off the logic that the sim should be framerate independent, which for some reason doesn't seem to be the case despite our use of FixedUpdate, and then just runs it for a fixed time duration. We can change it to instead try to meet some new rotation and just keep rotating until it hits that value, which should truly be framerate independent.

Just wanted to give a heads up that we'll look into this soon! We'll try to fix this up in the next week.

[thisjustin123]

Just a heads up--I am working on this now. Here's a demo of the rotation being a lot more precise than before:

(Roughly 90-degree left turn)

2024-10-03.20-15-44.mp4

Still testing and tuning. Thanks for your patience!

[ALaws0n]

Hello,

In the video above, are you completing the turn by only calling TurnLeft(90, speed) on the robot, or are you also moving the position of the gripper?

[YoruCathy]

Hi @ALaws0n , we've updated the simulation environment and the example in the latest commit. Check it out!