@GiulioRomualdi @S-Dafarra
I have been testing the walking controller along side floating base estimation device. The robot tends to fall every time I run the WalkingModule and the module exits unanimously.
The walking parameters are default as the ones available in the repository, except for the following changes,
use_mpc flag is commented in walkingCoordinator.ini disabling the use of mpcsolver is set to mumps in inverseKinematics.ini
The steps followed to run the WalkingModule are as described in the README. I have been using setGoal 0.3 0.0 as input.
Background on floating base estimation device. This is a YARP device opening and attaching itself to the remote control boards of all parts of the iCubGazeboV2_5 robot. It also opens and attaches itself to the wholeBodyDynamics device. A transformServer is also opened in order to publish transforms to ROS \tf topic. The regular workflow involves also running a yarprobotstatepublisher along with rviz to visualize the estimation. All of this along with Gazebo is already a considerable load on the computer memory, causing things to slow down. In the involved components, rviz and Gazebo are quite heavy with respect to the PC's capability (8GB RAM 2.5GHz 4-core CPU)
I suspect the fact that both walking-controller and floating-base-estimation talks with whole-body-dynamics and this causes the walking-controller to not get the required Cartesian wrench feedback within the update period of the controller is causing the failure ? However, this is just my naive speculation.
I would ask about your opinion on why this failure could happen ? and precautions to avoid this failure.
@GiulioRomualdi @S-Dafarra
I have been testing the walking controller along side floating base estimation device. The robot tends to fall every time I run the
WalkingModuleand the module exits unanimously.The walking parameters are default as the ones available in the repository, except for the following changes,
use_mpcflag is commented inwalkingCoordinator.inidisabling the use of mpcsolveris set tomumpsininverseKinematics.iniThe steps followed to run the
WalkingModuleare as described in the README. I have been usingsetGoal 0.3 0.0as input.Background on floating base estimation device. This is a
YARP deviceopening and attaching itself to theremote control boardsofall partsof theiCubGazeboV2_5robot. It also opens and attaches itself to thewholeBodyDynamicsdevice. AtransformServeris also opened in order to publish transforms to ROS\tftopic. The regular workflow involves also running ayarprobotstatepublisheralong withrvizto visualize the estimation. All of this along withGazebois already a considerable load on the computer memory, causing things to slow down. In the involved components,rvizandGazeboare quite heavy with respect to the PC's capability (8GB RAM 2.5GHz 4-core CPU)I suspect the fact that both walking-controller and floating-base-estimation talks with whole-body-dynamics and this causes the walking-controller to not get the required Cartesian wrench feedback within the update period of the controller is causing the failure ? However, this is just my naive speculation.
I would ask about your opinion on why this failure could happen ? and precautions to avoid this failure.