a issue about sim2real

[a2821952]

Hello, I try to excute whole_body_controller_example in the pybullet and it works well. When I use whole_body_controller_robot_example in a real A1 robot with MPC, I found that the robot was moving so fast that it could't keep its balance, so I tried to adjust some parameters such as time_step, action_repeat and time.sleep but falied to solve the problem of violent movement. Have you encountered any similar problems in real A1 robot? Is there any setting I have missed?

[yxyang]

What do you mean by "moving fast"? Is it that the legs oscillate too much, or the robot's body moving forward too fast? Do you have a video to better illustrate the situation? It would be much easier to understand the issue that way.

time_step/action_repeat are sim parameters only should not matter for the real robot.

To start, I'd suggest checking the following:

Which CPU/platform you are using and what's the control frequency it's achieving? That is, what is the wall-clock frequency you are running this while loop on the real robot?

For the controller to work well, it requires a minimum control frequency of ~300Hz. If your control frequency is too low, consider using a faster CPU.

If the control frequency is too high (>600Hz), its sensor readings may be too noisy. In this case, try increasing the window_size in velocity estimator, which should smooth out things more.

[yxyang]

Closing the issue for now. Feel free to re-open if it still exists.

[voyagerahn]

Hello, I'm doing some test with real A1 robot. I try to excute whole_body_controller_example.py During that times, robot's leg oscillate too much at least once in 10 times. Especially in situations that the height of the body is raised.(MPC_BODY_HEIGHT 0.24 -> 0.28) even if the program is re-executed, the robot's motor does not work. but It works well after rebooting. i wonder Is this a control frequency problem? If so, how can i check the real control frequency? Thank you in advance.

[yxyang]

To check control frequency, I suggest just logging the time using time.time() for each control step. As long as the frequency is over 300Hz, I would say that it should be sufficient for your application.

Kind of weird that it all "works well after rebooting". Are you saying that it only works the first time after rebooting, but not afterwards?

[voyagerahn]

Thank you for answering my question. I mean it works well even if I executes program several times after rebooting. However, the robot's motor doesn't respond often. So I do reboot again and then works well until it does not respond. I guess it happens more often when the error(desired value - current state) is large. Do you have a similar phenomenon?

[yxyang]

Haven't seen this issue before.

By rebooting, do you mean just rebooting the computer, or rebooting the computer and the robot? By "does not respond", do you mean motors stay fixed in their original position, enter joint damping mode (slowly falls down), or completely turns off?

If it's entering joint-damping mode, it's likely a control frequency issue. Also double check that you have a good ethernet connection to the robot's motherboard.

[voyagerahn]

The first answer is to reboot the robot not computer( onboard PC of the robot is not used as a limitation of performance.) Second, "does not reply" means robot's motor enter joint damping mode and then It doesn't respond to commands if i command torque to robot (LowCmd). but its state(Lowstate) is well printed in this situation(It means ethernet connection isn't problem).

Thank you for answering my question. i will check frequency issue. thanks a lot!

[yxyang]

Not exactly sure what is happening in your case. On the robot side, if it does not receive a new control command for a while (a few milliseconds), it will switch to joint damping for safety concerns.

[voyagerahn]

Thank you!