gbionics / gbionics/walking-controllers
iCubGazeboV2_5 robot falling before completing walking trajectory
- Dominant language
- C++
- Stars
- 162
- Forks
- 51
- PR merge metrics
- No merged PRs in 30d
Description
@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 mpc
- `solver` 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.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.