-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sending 0 torques results in non-zero torques applied. #68
Comments
Which kind of torques are you measuring (you can read that on the robotMotorGui) at the joint at which you command a desired torques of 0 Nm? |
However to debug the problem you can use the |
The wbi "read Torques" block returns torques up to 1.4Nm |
True that I could use the demoForceControl to achieve zero torques. But the original purpose was to implement a PD controller for position tracking, and if the torques provided are not the ones applied, that is a major problem. |
@robertocalandra are you setting some sort of gravity compensation? The behaviour seems compatible with zero torques at the joint and no gravity compensation. |
I tried with both gravity compensation and without gravity compensation and the results are qualitatively equal. I would however expect that even in presence of no gravity compensation the controller would still apply zero torques and therefore the torso "slowly" fall down naturally due to the gravity. This is not the case as the torso is actively pushing down. |
What happens with the |
The robot seems to behave normally for the two arms. I did not try the torso as it is marked as experimental. Should I? |
@robertocalandra The video you posted refers to a trial with or without gravity compensation? |
@iron76 If we go into zero torque mode (from demoForceControl), the behavior is the same (strong push forward of the torso). I do not remember if the gravity compensation was activated or not in the video. |
could you please tell me the measured joint torques of the 3 joints of the 2015-01-28 20:11 GMT+01:00 Roberto Calandra [email protected]:
|
@robertocalandra, in any case the zero torque control is definitively quite a a risky control mode and I would recommend doing tests in impedance. |
PS: ...not only the three torques when in 0,0,0 but also when the joints 2015-01-28 20:35 GMT+01:00 Francesco Nori [email protected]:
|
I do agree with @iron76 that the zero-torque control is quite risky, and should be avoided even for debugging. If the torso strongly pushes forward, however, there might be a problem at low level. A possible issue might be due to the coupling between the (desired) joint torques and the applied PWMs to the motors 0B3M0 and 0B3M1 (see http://wiki.icub.org/wiki/ICub_coupled_joints#Torso). Probably @randaz81 may clarify this and claim whether or not the problem may be due to this coupling handling. |
@DanielePucci Coupling is correct. Otherwise in the video the robot should move diagonally. |
@randaz81 Here there are the torque measurementes are in the robotMotorGui (using wholeBodyDynamicsTree), averaged over 5 seconds. [0,0,0] ->[0.01, -0.2 -4.4] |
Could be an issue with wholeBodyDynamicsTree ? Which options are you using? You obtain similar results with the old wholeBodyDynamics? |
@traversaro I cannot test it today, as the robot is being used for other experiments, I will let you know tomorrow |
@traversaro These are the results using the wholeBodyDynamics: [0,0,0] -> [0.03, -0.18, -4.3] I would say that they are qualitatively similar. Question: the torso skin is currently dismounted (because of a faulty connection), as shown also in the video, could that be the problem? |
PS: I am using the options --headV2 --autoconnect |
I tried the following setup: robot name: iCubGenova04, mechanics revision V1, ETH communication 2015-01-30 11:52 GMT+01:00 Roberto Calandra [email protected]:
|
Before proceeding any further, I recommended to sync your robot with our test case, with a general update of yarp, icub-main, icub-firmware-shared. This to eliminate the possibility that you are stuck to a bugged old revision of something. |
If so, yes, let's proceed with updating yarp, icub-main, etc; and yes, I would definitely like to have remote support (especially for the control board firmware). PS: since it is a very high priority for us, I am available today, tomorrow and even on sunday. |
@randaz81 Please let me know the earliest availability for remote support. |
I can confirm that after the update the issue is still present: Using zero torque control (with gravity compensation and wholebodydynamics modules running) causes a fast bending of the torso forward. Additionally after updating yarp and icub-main
|
Have you updated (or at least recompiled) codyco-superbuild after updating On Wed, Feb 4, 2015 at 11:41 AM, Roberto Calandra [email protected]
|
Yes, of course I did recompile the codyco-superbuild. |
Mhh then it is possible that there are two different versions of YARP floating in the system... perhaps the codyco-superbuild is building an incompatible version of YARP? |
|
Ok, my hypothesis is wrong. Just to clarify:
In any case, it can be useful to debug to paste the output of ldd /path/to/wholeBodyDynamics and ldd /path/to/yarpserver , just to understand what's different between a working binary and a not workign one. |
Sorry Silvio, there was a typo in my previous post: |
Ok, then |
It seems that there are two wholeBodyDynamicsTree. is it normal?
|
Yes, it make sense that there are two wholeBodyDynamicsTree: the superbuild automatically installs all its subproject in the build/install directory, so you will find the same binary in the build directory and in the install directory. However this output highlighted the problem: the binaries of the codyco-superbuild are using the YARP libraries from |
The issue is still open after completely reinstalling the codyco-superbuild from scratch. PS: the issue is clearly not wbi-related. |
Once more, pure torque control is a nonsense without perfect modelling (which is i.m.h.o. a chimera). It's even worse considering that you are debugging. @robertocalandra can you please do impedance control instead? Just to be more clear. Control mode should be |
We are having serious difficulties in commanding in torque the iCubDarmstadt01 from the wbi.
After switching on the wholeBodyDynamicsTree, if we try to send a zero torque using the set Torque block of the wbi, the icub apply a strong force forward.
I am not sure if it is because of errors in the wholeBodyDynamicsTree, because of the low-level firmware or what else.
However, it is critical for us to fix this problem as soon as possible. Would it be possible to have ASAP a skype meeting with someone to diagnose and solve it?
For a video see https://www.dropbox.com/s/3g9cwr3bk44v5lt/VID_20150128_181413.mp4
PS: this bug happen when using the older version of the wbi (v0.1)
The text was updated successfully, but these errors were encountered: