The getIsStancePhase logic on devel is broken

[S-Dafarra]

We noticed that while testing #65, the robot was not able to walk anymore. When substituting https://github.com/robotology/walking-controllers/blob/2d0a4a5e0c851b05c001b15b17abadf2aea257fe/src/WalkingModule/src/Module.cpp#L667 with

double threshold = 0.001;
bool stancePhase = iDynTree::toEigen(m_DCMVelocityDesired.front()).norm() < threshold;
m_walkingZMPController->setPhase(stancePhase);

we managed to restore the expected performances.
cc @GiulioRomualdi

[S-Dafarra]

While looking at the code, the line https://github.com/robotology/walking-controllers/blob/2d0a4a5e0c851b05c001b15b17abadf2aea257fe/src/TrajectoryPlanner/src/TrajectoryGenerator.cpp#L669 is suspicious.
The Clang static analyzer is showing the following warning:

TrajectoryGenerator.cpp:669: warning: multiple unsequenced modifications to 'stancePhaseDelayCounter'

Indeed, its behavior is probably undefined https://stackoverflow.com/questions/47507558/multiple-unsequenced-modifications-to-a-a-a.

This may be coherent with the fact that the robot seems to never exit the stance phase. A possible fix is

stancePhaseDelayCounter = stancePhaseDelayCounter == 0 ? 0 : stancePhaseDelayCounter - 1;

We may try this on the robot and check if it is working.

[S-Dafarra]

Unfortunately, the patch proposed in #66 (comment) does not fix the problem.

[GiulioRomualdi]

I've probably found the bug. m_isStancePhase is not advanced like the others. This means that we are always in the stance phase even if the robot is walking. I open a PR for fixing this. If @S-Dafarra and @prashanthr05 are going to test something on the robot I would give it a try.

[S-Dafarra]

I've probably found the bug. m_isStancePhase is not advanced like the others. This means that we are always in the stance phase even if the robot is walking. I open a PR for fixing this. If @S-Dafarra and @prashanthr05 are going to test something on the robot I would give it a try.

I can give it a try!

[GiulioRomualdi]

That's the PR: #68

[GiulioRomualdi]

#68 fixes the problem. We can close the issue