Closed itaouil closed 2 years ago
Hi @itaouil we just updated the debians. Can you let us know if it solves the problems? Thank you
Hi @graiola,
Thanks a lot for the push :).
I just tried it but for all the robots I tried they just hang in the air.
I also have the following error (which I don't think I ever had before)
I guess this package is missing which seems to be the one responsible to set the robot to the starting position. I tried to locate the package but could not find it.
Hi @itaouil , I forgot to add the installation of a script. I just updated the debian package of wb_controller to fix that.
Hi @graiola,
Thanks again to you and Enrico for the changes and the help :).
I tried the new debs and from the tests I made so far it works way better for the AlienGo robot. I tried with all the combinations in which it used to fail previously and this time did not fail at all.
While I was testing I noted that the joint positions are different than before, and as soon as the robot starts walking the robot acquires a different form.
This is what I mean:
Starting joint positions (once the solver is on)
After a few steps:
Joints warnings received:
Maybe this is something you and Enrico changed to deal with the failure during the rotation and/or to keep the robot more stable during motion?
I also took a video to show how the robot behaves (https://drive.google.com/file/d/1zlGBXJq2LmDzu2KhheiI_kZ-uDXrY5Z7/view?usp=sharing). The wbc failed at the end, but I think this was only due because I set a linear velocity of 1.0. I tried it again afterwards and even though sometimes it seems to be going to fall, and prints some warning like the ones below, it remains stable :).
I will do some more tests tomorrow and will keep you updated but the changes seems promising :). Out of curiosity what did you end up changing?
In this debians we mainly changed the stack and the strategy to control the CoM. Minor changes regards also some optimization in the problem formulation (less variables) and the Cartesian control of the legs. Concerning the joint limits, we are going to investigate this issue, it could be caused by a non-perfect tracking of the feet, but we have a joint-limits constraint that we did not yet add to the stack, this could solve the problem.
Amazing!
I will do some further testing today but I will close this issue for the moment and move the joint-limits constraints discussion to a new issue.
Hi,
As mentioned in issue #4 there are times where the wbc suddenly fails while a linear reference velocity is commanded:
Case 1:
Sudden change in the linear velocity (https://drive.google.com/file/d/1Gnlj-lxAZ1jkON09iWCssMsvGKuzrtBl/view?usp=sharing). Here I was playing with the linear velocity and when I suddenly changed it from around 0.7 to around 0.4 the robot failed. Maybe it is due to the sudden change?
Case 2:
Step-wise change in the linear velocity (https://drive.google.com/file/d/1UhCx-SkGlE3kGogm-3B3F9LYJkEccuKW/view?usp=sharing). Here I was giving increasingly larger velocities but not while the robot was in movement. At 0.7 velocity and after a few seconds it failed. This test was in order to check if maybe case 1 failure was indeed due to the sudden change in the velocity.
The wbc also failed during a rotational movement, but here as you can see in the video the robot was becoming unstable before falling, while in the previous two cases there wasn't really a sign of unstability:
Case 3:
Continuous rotation (https://drive.google.com/file/d/1qBomvBgDhYLUuRjbBL7IwLznpYhWsuU8/view?usp=sharing). Here I was given as reference a constant angular velocity of 0.4 and the robot lost balance after half rotation.
The recurrent error message between all of the cases is Step length larger than 0.5. Have you even experienced the same issue before while testing it in simulation or in the real HyQ robot?