Closed SimoneMic closed 2 years ago
mebbaid
commented
2 years ago ciao @SimoneMic , are you available tomorrow in IIT for a f2f (preferably after 14:00) ? so that we can compare our set-ups to see if there is any difference and try to debug/iterate.
SimoneMic
commented
2 years ago ciao @SimoneMic , are you available tomorrow in IIT for a f2f (preferably after 14:00) ? so that we can compare our set-ups to see if there is any difference and try to debug/iterate.
Unfortunately this week I'm not in Genova, but the next one I'll be there.
mebbaid
commented
2 years ago ok, we can arrange a ms-teams meeting tomorrow, because (at least to me, others can be more helpful here) it is difficult to debug without going through the set-up thoroughly.
SimoneMic
commented
2 years ago Ok, thanks, fine by me.
From: Mohamed Elobaid @.> Sent: Monday, February 14, 2022 6:53:06 PM To: robotology/walking-controllers @.> Cc: Simone Micheletti @.>; Mention @.> Subject: Re: [robotology/walking-controllers] iCubGazebo_V3 Falls Frequently in Simulation on Gazebo (Issue #107)
ok, we can arrange a ms-teams meeting tomorrow, because (at least to me, others can be more helpful here) it is difficult to debug without going through the set-up thoroughly.
— Reply to this email directly, view it on GitHubhttps://github.com/robotology/walking-controllers/issues/107#issuecomment-1039379512, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUXEKH4RZIULPO44LWZAHULU3E6QFANCNFSM5OMCWNHA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.***>
SimoneMic
commented
2 years ago Hello,
Me and @mebbaid saw that the gazebo real time factor fell pretty low in simulation,around 0.40 - 0.45 after spawning the model. I was streaming on Teams, so the computational load of the application was slowing a bit the simulation, but - without any other applications - during the walking is around 0.6 (still not great either).
This is compliant to the error that gives the walking module when the robot falls:
[ERROR] [evaluateZMP] None of the two contacts is valid.
[ERROR] [WalkingModule::updateModule] Unable to evaluate the ZMP.It seems that the robot doesn't perceive the contacts on its feets.
We did the following tests on my configuration (iCubGazeboV3):
real_time_update_rate to 0 to make it run as fast as it can. This led to a real time factor of 1.25 in simulation. But we found out that the prepareRobot phase failed when having a real time factor > 1. Here's the error code.
q desired IK 18.5369 0.236021 -0.05871 -1.91926 16.7715 -12.6683 39.7101 -1.95081 16.789 -12.6609 39.7137 2.59106 0.623582 -0.289821 -58.3052 -33.6794 -0.731743 2.62289 0.494828 -0.223192 -58.3616 -33.7034 -0.498707
[ERROR] [RobotInterface::checkMotionDone] The timer is expired but the joint r_knee has an error of 1.01871 radians
[ERROR] [WalkingModule::updateModule] Unable to check if the motion is done
[INFO] [WalkingModule::updateModule] Try to prepare againNote: this doesn't happen when real_time_update_rate is set to 1000 Hz, but when is at 0.
gzserver, with a world file (see attachment), with real time factor of 1. But the simulation kept having a small real time factor of 0.3/0.4 and the robot fell in a short while.Other information: I have the latest versions of walking-controllers, unicycle footstep planner. Also I have gazebo 11 and the latest version of YARP (3.6).
Anyone has any suggestions? Thanks
mebbaid
commented
2 years ago Other information: I have the latest versions of walking-controllers, unicycle footstep planner. Also I have gazebo 11 and the latest version of YARP (3.6).
yeah, I should start by saying that, apart from using the super-build , the individual relevant repositories were aligned in both our machines. Alas, I was not able to reproduce the errors and constant falls/failure upon startup of the WalkingModule.
lrapetti
commented
2 years ago @SimoneMic probably a video of the failure might also be of help for debugging your issue
SimoneMic
commented
2 years ago Here's a video iCubGazebo_Fall.zip
Let me know if you need something else.
SimoneMic
commented
2 years ago I've also tried to run the configuration presented in https://github.com/robotology/walking-controllers/blob/fc74f101e1e933ac6b89e28ca52559ef18d4cd9a/src/WalkingModule/app/robots/iCubGenova09/dcm_walking/joypad_control/robotControl.ini#L21-L25
running the ankle joints in compliant mode (as suggested by @lrapetti ). But the robot fell forward right after the startWalking command.
Here's the log:
q desired IK 18.5369 0.236021 -0.05871 -1.91926 16.7715 -12.6683 39.7101 -1.95081 16.789 -12.6609 39.7137 2.59106 0.623582 -0.289821 -58.3052 -33.6794 -0.731743 2.62289 0.494828 -0.223192 -58.3616 -33.7034 -0.498707
[INFO] [WalkingModule::updateModule] The robot is prepared.
IK: 1.475400 ms Total: 2.669100 ms
IK: 0.965000 ms Total: 2.098400 ms
IK: 1.008600 ms Total: 2.024900 ms
IK: 1.129500 ms Total: 2.342200 ms
IK: 0.954300 ms Total: 1.771800 ms
IK: 0.814500 ms Total: 1.600900 ms
IK: 1.162400 ms Total: 2.243900 ms
IK: 0.945400 ms Total: 1.495000 ms
IK: 1.126000 ms Total: 2.373200 ms
IK: 0.799600 ms Total: 1.718600 ms
IK: 0.978500 ms Total: 1.764800 ms
IK: 1.428200 ms Total: 2.525300 ms
[ERROR] [RobotInterface::setDirectPositionReferences] The worst error between the current and the desired position of the l_shoulder_roll joint is greater than 0.5 rad.
[ERROR] [WalkingModule::updateModule] Error while setting the reference position to iCub.
[INFO] |yarp.os.RFModule| RFModule closing.
[INFO] |yarp.os.impl.PortCoreInputUnit|/walking-coordinator/left_foot_front/cartesianEndEffectorWrench:i| Removing input from /wholeBodyDynamics/left_foot_front/cartesianEndEffectorWrench:o to /walking-coordinator/left_foot_front/cartesianEndEffectorWrench:i
[INFO] |yarp.os.impl.PortCoreInputUnit|/walking-coordinator/left_foot_rear/cartesianEndEffectorWrench:i| Removing input from /wholeBodyDynamics/left_foot_rear/cartesianEndEffectorWrench:o to /walking-coordinator/left_foot_rear/cartesianEndEffectorWrench:i
[INFO] |yarp.os.impl.PortCoreInputUnit|/walking-coordinator/right_foot_front/cartesianEndEffectorWrench:i| Removing input from /wholeBodyDynamics/right_foot_front/cartesianEndEffectorWrench:o to /walking-coordinator/right_foot_front/cartesianEndEffectorWrench:i
[INFO] |yarp.os.impl.PortCoreInputUnit|/walking-coordinator/right_foot_rear/cartesianEndEffectorWrench:i| Removing input from /wholeBodyDynamics/right_foot_rear/cartesianEndEffectorWrench:o to /walking-coordinator/right_foot_rear/cartesianEndEffectorWrench:i
[INFO] |yarp.os.impl.PortCoreOutputUnit|/walking-coordinator/remoteControlBoard/icubSim/torso/rpc:o| Removing output from /walking-coordinator/remoteControlBoard/icubSim/torso/rpc:o to /icubSim/torso/rpc:i
[INFO] |yarp.os.impl.PortCoreOutputUnit|/walking-coordinator/remoteControlBoard/icubSim/torso/command:o| output for route /walking-coordinator/remoteControlBoard/icubSim/torso/command:o->udp->/icubSim/torso/command:i asking other side to close by out-of-band means
[INFO] |yarp.os.impl.PortCoreOutputUnit|/walking-coordinator/remoteControlBoard/icubSim/torso/command:o| Removing output from /walking-coordinator/remoteControlBoard/icubSim/torso/command:o to /icubSim/torso/command:i
[INFO] |yarp.os.impl.PortCoreInputUnit|/walking-coordinator/remoteControlBoard/icubSim/torso/stateExt:i| Removing input from /icubSim/torso/stateExt:o to /walking-coordinator/remoteControlBoard/icubSim/torso/stateExt:i
[INFO] |yarp.os.impl.PortCoreOutputUnit|/walking-coordinator/remoteControlBoard/icubSim/left_arm/rpc:o| Removing output from /walking-coordinator/remoteControlBoard/icubSim/left_arm/rpc:o to /icubSim/left_arm/rpc:i
[INFO] |yarp.os.impl.PortCoreOutputUnit|/walking-coordinator/remoteControlBoard/icubSim/left_arm/command:o| output for route /walking-coordinator/remoteControlBoard/icubSim/left_arm/command:o->udp->/icubSim/left_arm/command:i asking other side to close by out-of-band means
[INFO] |yarp.os.impl.PortCoreOutputUnit|/walking-coordinator/remoteControlBoard/icubSim/left_arm/command:o| Removing output from /walking-coordinator/remoteControlBoard/icubSim/left_arm/command:o to /icubSim/left_arm/command:i
[INFO] |yarp.os.impl.PortCoreInputUnit|/walking-coordinator/remoteControlBoard/icubSim/left_arm/stateExt:i| Removing input from /icubSim/left_arm/stateExt:o to /walking-coordinator/remoteControlBoard/icubSim/left_arm/stateExt:i
[INFO] |yarp.os.impl.PortCoreOutputUnit|/walking-coordinator/remoteControlBoard/icubSim/right_arm/rpc:o| Removing output from /walking-coordinator/remoteControlBoard/icubSim/right_arm/rpc:o to /icubSim/right_arm/rpc:i
[INFO] |yarp.os.impl.PortCoreOutputUnit|/walking-coordinator/remoteControlBoard/icubSim/right_arm/command:o| output for route /walking-coordinator/remoteControlBoard/icubSim/right_arm/command:o->udp->/icubSim/right_arm/command:i asking other side to close by out-of-band means
[INFO] |yarp.os.impl.PortCoreOutputUnit|/walking-coordinator/remoteControlBoard/icubSim/right_arm/command:o| Removing output from /walking-coordinator/remoteControlBoard/icubSim/right_arm/command:o to /icubSim/right_arm/command:i
[INFO] |yarp.os.impl.PortCoreInputUnit|/walking-coordinator/remoteControlBoard/icubSim/right_arm/stateExt:i| Removing input from /icubSim/right_arm/stateExt:o to /walking-coordinator/remoteControlBoard/icubSim/right_arm/stateExt:i
[INFO] |yarp.os.impl.PortCoreOutputUnit|/walking-coordinator/remoteControlBoard/icubSim/left_leg/rpc:o| Removing output from /walking-coordinator/remoteControlBoard/icubSim/left_leg/rpc:o to /icubSim/left_leg/rpc:i
[INFO] |yarp.os.impl.PortCoreOutputUnit|/walking-coordinator/remoteControlBoard/icubSim/left_leg/command:o| output for route /walking-coordinator/remoteControlBoard/icubSim/left_leg/command:o->udp->/icubSim/left_leg/command:i asking other side to close by out-of-band means
[INFO] |yarp.os.impl.PortCoreOutputUnit|/walking-coordinator/remoteControlBoard/icubSim/left_leg/command:o| Removing output from /walking-coordinator/remoteControlBoard/icubSim/left_leg/command:o to /icubSim/left_leg/command:i
[INFO] |yarp.os.impl.PortCoreInputUnit|/walking-coordinator/remoteControlBoard/icubSim/left_leg/stateExt:i| Removing input from /icubSim/left_leg/stateExt:o to /walking-coordinator/remoteControlBoard/icubSim/left_leg/stateExt:i
[INFO] |yarp.os.impl.PortCoreOutputUnit|/walking-coordinator/remoteControlBoard/icubSim/right_leg/rpc:o| Removing output from /walking-coordinator/remoteControlBoard/icubSim/right_leg/rpc:o to /icubSim/right_leg/rpc:i
[INFO] |yarp.os.impl.PortCoreOutputUnit|/walking-coordinator/remoteControlBoard/icubSim/right_leg/command:o| output for route /walking-coordinator/remoteControlBoard/icubSim/right_leg/command:o->udp->/icubSim/right_leg/command:i asking other side to close by out-of-band means
[INFO] |yarp.os.impl.PortCoreOutputUnit|/walking-coordinator/remoteControlBoard/icubSim/right_leg/command:o| Removing output from /walking-coordinator/remoteControlBoard/icubSim/right_leg/command:o to /icubSim/right_leg/command:i
[INFO] |yarp.os.impl.PortCoreInputUnit|/walking-coordinator/remoteControlBoard/icubSim/right_leg/stateExt:i| Removing input from /icubSim/right_leg/stateExt:o to /walking-coordinator/remoteControlBoard/icubSim/right_leg/stateExt:i
[INFO] |yarp.os.RFModule| RFModule finished.
[WARNING] |yarp.os.NetworkClock| Destroying network clock
[INFO] |yarp.os.Network| Success: port-to-port persistent connection added.
[INFO] |yarp.os.impl.PortCoreInputUnit|/IITICUBLAP249/WalkingModule/8465/clock:i| Removing input from /clock to /IITICUBLAP249/WalkingModule/8465/clock:iI didn't even issued a setGoal command.
mebbaid
commented
2 years ago @S-Dafarra @GiulioRomualdi
GiulioRomualdi
commented
2 years ago Hi @SimoneMic, the long story short is that I never spent a lot of time tuning the controller in simulation for iCubGazeboV3. For this reason, the set of gains may not be optimal. Here are some hints:
[ERROR] [evaluateZMP] None of the two contacts is valid.
[ERROR] [WalkingModule::updateModule] Unable to evaluate the ZMP.[ERROR] [RobotInterface::setDirectPositionReferences] The worst error between the current and the desired position of the l_shoulder_roll joint is greater than 0.5 rad. appears if the position tracking error of a joint, in this case, the l_shoulder_roll, is pretty high. This is due to the low-level position control.running the ankle joints in compliant mode
The compliant mode has been tested only on the real robot as a consequence I've never tuned the low-level gains for the compliant mode in simulation. Furthermore, the walking does not provide any interface to set them. If you want to change them you should open a pr in icub-models-generator
S-Dafarra
commented
2 years ago @GiulioRomualdi @SimoneMic @mebbaid maybe it would be also worth to drop here some data saved with the (new) logger. Maybe we manage to find something suspicious
lrapetti
commented
2 years ago running the ankle joints in compliant mode
The compliant mode has been tested only on the real robot as a consequence I've never tuned the low-level gains for the compliant mode in simulation. Furthermore, the walking does not provide any interface to set them. If you want to change them you should open a pr in icub-models-generator
Concerning this point, all the parameters for complaint mode are actually set to zero in iCubGazeboV3 (and same for iCubGazeboV2_5). Just as reference, we could try the parameters tuned on the real robot (that can be found here)
SimoneMic
commented
2 years ago Hello
Today me and @mebbaid tried using a docker to see if the simulation has the same behavior and presents the same issues. We had the following results:
iCubGazeboV3 falls on both computer and has a similar behavior, although on @mebbaid PC the RTF is higher - around 0.9 vs mine at 0.65 (same laptop model).[ERROR] [evaluateZMP] None of the two contacts is valid. [ERROR] [WalkingModule::updateModule] Unable to evaluate the ZMP.stickBot model (for the ErgoCub project) presents this issue (further tuning needed, since some parameters change).If you want to use the same docker you can pull it with the following command: sudo docker pull simonemiche/ergocub_simulation:test1
To run it: sudo docker run -it -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix${DISPLAY} --device /dev/dri/card0:/dev/dri/card0 --network=host --privileged simonemiche/ergocub_simulation:test1 bash
The docker has a clean installation of the robotology superbuild using cmake.
mebbaid
commented
2 years ago As per our last discussion, me and @SimoneMic have arrived at a new set of gains for the low level position-control pid that works OK for the stickBot in both our machines. Additionally those gains seems to work as well, in my machine, for the iCubGazeboV3. These gains will update the icub-model-generator repo.
SimoneMic
commented
2 years ago I think that we can close this issue. With @mebbaid pid parameters there's a stable improvement and the simulations are more reliable. The robot still falls after a while, but lasts enough for testing localization algorithms and motion planning. For mapping it could be another topic, but that could be a separate issue for future plans.
Thanks all!
Hello everybody!
I am using in simulation (Gazebo) the iCubGazebo_V3 (no hands) model and it keeps falling after a little while. The best I could do is 4 meters in a straight line. I have followed step-by-step the instructions in https://github.com/robotology/walking-controllers#computer-how-to-run-the-simulation and I'm controlling it via
yarp rpc /walking-coordinator/rpcusing the commandsetGoal x y.I have also tried to wait the robot to reach the setGoal location and to relaunch the command, like a stop-and-go, but it never manages to go after the third command that it falls. So it would seem that in continuous walking it behaves better.
I have also used the pid parameters suggested by @mebbaid in the following link: https://github.com/robotology/icub-models/pull/126/files but to no avail.
I am using the latest build of walking-controllers (master).
Here I attach the terminal output of the walking module.
Maybe I am missing something that I can't see.
Thank you
cc @lrapetti @randaz81