sot-talos-balance issueshttps://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues2020-01-30T09:24:20Zhttps://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/108Mismatch between torques computed with RNEA from WPG and measured one2020-01-30T09:24:20ZOlivier StasseMismatch between torques computed with RNEA from WPG and measured oneThere is a mismatch between the torques computed with RNEA from WPG and the measured one.
The configuration trajectories are correct.
The experiment and the results are described here:
https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/...There is a mismatch between the torques computed with RNEA from WPG and the measured one.
The configuration trajectories are correct.
The experiment and the results are described here:
https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/wikis/Experiment-2020-01-27-18-48-Half-step-forward-20-cm-SS-0.9-DS-0.115https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/106Calibrating dynamic model2019-11-20T15:38:53ZGabriele BuondonnoCalibrating dynamic modelI believe we should calibrate the dynamic model.
I see a huge difference between the measured foot forces and the desired ones computed by using the model.
In particular, the total weight of the robot, as measured by the foot force senso...I believe we should calibrate the dynamic model.
I see a huge difference between the measured foot forces and the desired ones computed by using the model.
In particular, the total weight of the robot, as measured by the foot force sensors, seems to be much higher than the Pinocchio model mass (about 10kg difference).
@ostasse, what are the results of the calibration you did with Vincent?
If there is no significant difference with the PAL model, then the problem is probably in the force sensors themselveshttps://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/105Foot force control2019-10-30T14:55:24ZGabriele BuondonnoFoot force controlIn Stephane's paper, there is the notion of *Foot Force Difference Control*.
This is only during double support phase, and it only concerns the vertical z-axis.
Thanks to the last property, a simple heuristics is certainly enough to dis...In Stephane's paper, there is the notion of *Foot Force Difference Control*.
This is only during double support phase, and it only concerns the vertical z-axis.
Thanks to the last property, a simple heuristics is certainly enough to distribute the vertical component between right and left. Therefore, it can be tested even before having solved the problems with the QP distribution. I am testing it in simulation and it seems to work well.
Additionally, I am implementing an admittance control on the swing foot, so that if the impact force is too string this will mitigate it. Simulations results seem encouraginghttps://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/101Provide rho and phase files for test trajectories.2019-09-10T20:39:52ZGabriele BuondonnoProvide rho and phase files for test trajectories.On my fork, in [test_dcm_zmp_control_distribute.py](https://gepgitlab.laas.fr/gbuondon/sot-talos-balance/blob/devel/python/sot_talos_balance/test/test_dcm_zmp_control_distribute.py), I am testing the control scheme with the QP problem re...On my fork, in [test_dcm_zmp_control_distribute.py](https://gepgitlab.laas.fr/gbuondon/sot-talos-balance/blob/devel/python/sot_talos_balance/test/test_dcm_zmp_control_distribute.py), I am testing the control scheme with the QP problem resolution. This is a preliminary step for implementing the foot admittance.
This scheme needs two additional parameters: phase and rho.
Phase is an integer which is equal to zero during double support phase, while during the single support phase it is negative when on the right foot and positive when on the left foot.
Rho is a parameter rho=F_{zl}/(F_{zl}+F_{zr}), where F_{zl} and F_{zr} are the contact force on the right foot and on the left foot along the z-axis of the foot itself.
These should be put in two files: Phase.txt and Rho.txt, along with the others.
I managed to extract the phase from the Foot trajectories and recreate the file Phase.txt as needed. For rho, I followed a very simple heuristics (smooth transition from 0.4 to 0.6), which enabled me to partially validate the scheme in simulation, but it would be nice to have some more sensible values based on the dynamics as an output of the pattern generator. @ostasse, could you provide them?
By the way, I've just noticed there is a small error in my files at the end, I will fix this ASAP.https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/98Removing the integrator from the device2019-09-03T09:25:24ZOlivier StasseRemoving the integrator from the deviceFor compensating the flexibility we need to remove the integrator from sot-coreFor compensating the flexibility we need to remove the integrator from sot-coreNoelie RamuzatNoelie Ramuzathttps://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/97Fix state estimation2019-10-23T16:41:56ZGabriele BuondonnoFix state estimation@tflayols and I discovered the state estimation was not made correctly.
Upon further examination, we discovered the the update of the estimated feet position (i.e. the odometry and possibly the foot drift compensation) is not working. Th...@tflayols and I discovered the state estimation was not made correctly.
Upon further examination, we discovered the the update of the estimated feet position (i.e. the odometry and possibly the foot drift compensation) is not working. This was not a problem at all when doing tests on spot, such as executing a sinusoid with the CoM, but it causes estimation errors when walking forward.
The most likely explanation is a bug in the implementation, but we were not able to localize it.
@tflayols provided a quick fix. This provided a more rigorous state estimation, which is now working quite well. However, this basically discards an important part of the original state estimation scheme, and we think a real solution is badly needed.
I am still investigating the impact of the current fix, but the simulations do not seem to be particularly affected. It is important to confirm the results on the real robot, which I plan to do by Thursday, if the robot is working.https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/96Validate single ankle admittance control2019-07-11T15:05:57ZGabriele BuondonnoValidate single ankle admittance controlhttps://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/94Improve NdTrajectoryGenerator2019-07-11T07:09:53ZGabriele BuondonnoImprove NdTrajectoryGeneratorNdTrajectoryGenerator has lots of problems, especially concerning text file reading.
The idea is to abandon parametric-curves and switch to curves.
A summary of the main issues can be found here: https://gepgitlab.laas.fr/loco-3d/curves/...NdTrajectoryGenerator has lots of problems, especially concerning text file reading.
The idea is to abandon parametric-curves and switch to curves.
A summary of the main issues can be found here: https://gepgitlab.laas.fr/loco-3d/curves/issues/1https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/92Validate coupled admittance control2019-07-11T15:02:43ZGabriele BuondonnoValidate coupled admittance controlhttps://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/91Fix problem of spikes in time between one call to the controller and the next...2019-07-09T15:03:06ZGabriele BuondonnoFix problem of spikes in time between one call to the controller and the next one.This morning @ostasse and I made a few experiments to verify that basic walking still works and to investigate the problem of computation times found by a few people using sot-talos-balance.
We found that the walking still works, both on...This morning @ostasse and I made a few experiments to verify that basic walking still works and to investigate the problem of computation times found by a few people using sot-talos-balance.
We found that the walking still works, both on the master branch and on devel, and there seems not to be problems of computation time.
However, we noticed spikes in the time between one call to the SOT and the other. They are similar to what was seen in https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/issues/89#note_5216.
These happen both on the master branch and on devel. Further, we recovered data from the first walking experiments we made and we saw the spikes were already present.
This is probably not due to the controller itself, but to some lower level tool. It should be investigated.https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/89Fix noise in force distribution2019-07-09T14:51:52ZGabriele BuondonnoFix noise in force distributionRelated to #85 and #63.
As some of you were able to observe, the robot makes a terrible noise when running with the force distribution entity plugged, even when this entity is not sending anything to the controller but is simply present...Related to #85 and #63.
As some of you were able to observe, the robot makes a terrible noise when running with the force distribution entity plugged, even when this entity is not sending anything to the controller but is simply present in order to make its computations.
This is certainly the reflection of a deeper problem.
We suppose it might originate from some race conditions occurring during computations. I am going to investigate this.
The logs are in
```
2019_06_07
2019_06_19_gabriele
```
where the latter folder has some comments in the subfolders to explain what they are aboutGabriele BuondonnoGabriele Buondonnohttps://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/87State of sot-pattern-generator2019-09-10T13:45:54ZOlivier StasseState of sot-pattern-generatorState of sot-pattern-generator planed for 26/06/2019State of sot-pattern-generator planed for 26/06/2019https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/86Madgwick2019-06-19T13:28:00ZOlivier StasseMadgwickAsk to PAL if we can access to the low level interface of the IMU if madgwick is already included.Ask to PAL if we can access to the low level interface of the IMU if madgwick is already included.https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/85Validate Force distribution2019-06-19T17:31:14ZGabriele BuondonnoValidate Force distributionHi all,
today I've tried to validate the force distribution. The test was supposed to be identical to tests which are already working, except that in addition the force distribution was computed, without even sending the result as feedba...Hi all,
today I've tried to validate the force distribution. The test was supposed to be identical to tests which are already working, except that in addition the force distribution was computed, without even sending the result as feedback. I have no problems with that in simulation.
However, we did not manage to properly validate because the robot was making a terrible noise when executing the movement. We could not trace the origin of this noise, but it seems it was only doing it with the new test, not with the old one. This should be investigated further.
Also, when sending the robot in half sitting, more often than not the second joint of the left arm blocked itself, becoming red in the WebCommander. We could not understand why. We think it might come from the initial "clack" the robot does when activating the position controllers. But it was not doing it before!
@fcaminad and @frisbourg know more about it.
It might just be that the robot was not in good shape and on Monday everything will work.
If you want to test while I'm away:
in `python/sot_talos_balance/test`, run
```
python test_dcmZmpControl_distribute.py
```
At one point it will ask:
```
Calibrate force sensors?
```
Say yes. Then, when it's done, put the robot on the ground. Then it will ask:
```
Use output of force distribution?
```
say no at first.
Then
```
Execute a sinusoid?
```
Say yes.
Finally
```
Raise the foot?
```
SAY NO! It's not ready yet.
To examine the output of the wrench distribution, in `plot`:
```
rosrun plotjuggler Plotjuggler -l plot_wrenchDistrib.xml
```
If everything works fine (as it seemed to be), you can repeat the test by saying yes to the question
```
Use output of force distribution?
```https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/84File format2019-06-19T09:01:07ZGabriele BuondonnoFile formatCurrently, the script employing the stabilizer with trajectories read from text expects the following information:
- CoM.dat
- LeftFoot.dat
- RightFoot.dat
- WaistOrientation.dat
- optionally, ZMP.dat (if not given, it is computed from t...Currently, the script employing the stabilizer with trajectories read from text expects the following information:
- CoM.dat
- LeftFoot.dat
- RightFoot.dat
- WaistOrientation.dat
- optionally, ZMP.dat (if not given, it is computed from the CoM)
I was thinking that we should add another file for the upper body configuration, which will then be potentially time-varying and controlled in a purely kinematic way at the joint level.
Then I thought: instead of all this, we could have a single file containing the whole robot configuration, including the lower body and the freeflyer: position, velocity and acceleration. This would make the above files redundant, as all above quantities can be easily computed from the configuration.
The freeflyer and the joint angles for the legs will be probably only employed to compute the above quantities and then ignored, while the joint angles of the upper body will be directly fed to the SOT.
What do you think? Is there any reason to provide the above information separately from the configuration? I don't think there is any (except maybe the ZMP).
Should we change the specification so that we have a single file containing the whole configuration?https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/80Vertical control of the CoM2019-04-30T08:10:44ZGabriele BuondonnoVertical control of the CoMWe detected an oscillation of about 2.5cm in CoM height. This should be properly controlled. In a first phase, it should be kept constant.We detected an oscillation of about 2.5cm in CoM height. This should be properly controlled. In a first phase, it should be kept constant.https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/79Admittance control of the feet2019-04-24T12:54:15ZGabriele BuondonnoAdmittance control of the feetNow that the CoM admittance is basically closed, we should start thinking about the admittance on the feet.
Eventually, this will require the full implementation of the force distribution (#63), but I think we can do some tests which onl...Now that the CoM admittance is basically closed, we should start thinking about the admittance on the feet.
Eventually, this will require the full implementation of the force distribution (#63), but I think we can do some tests which only concern the admittance on the feet without the whole controller on.
Caron's paper implements admittance control on the ankles (#22) which only regulates the roll and pitch of the ankles, plus a special foot-force difference control which controls the difference in the forces exerted on the ground along the z-axis.
It was said long ago that it would be nice to directly switch to full-fledged admittance control of the feet, using the results of #32.
I am currently investigating the application of the end-effector admittance controller to the feet (on a separate branch). They seem to be easily applicable.
I like the idea of directly switching to 6D-admittance, but @tflayols is not convinced. I feel we should discuss it.https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/75Improve foot behaviour2019-04-18T09:36:53ZGabriele BuondonnoImprove foot behaviourThere are three problems with the foot behaviour when it is raised:
1. It is not fixed in the world frame
2. It is visibly vibrating
3. We could not put it back in the right position
I analysed the signals and I think I identified the ...There are three problems with the foot behaviour when it is raised:
1. It is not fixed in the world frame
2. It is visibly vibrating
3. We could not put it back in the right position
I analysed the signals and I think I identified the reason for the second point. In fact, the reference ZMP is vibrating a lot in simulation.
We are definitely going to run more experiments with the foot raised to explore these problemshttps://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/73Add an input signal for the maximum velocity in ControlManager2019-05-15T14:43:06ZThomas FlayolsAdd an input signal for the maximum velocity in ControlManagerNow, the value is hard-coded in a python configuration and is can not be axe dependent. An input of nq signal could solve this issue.Now, the value is hard-coded in a python configuration and is can not be axe dependent. An input of nq signal could solve this issue.https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/72Manage base reference frame2019-04-18T16:35:32ZGabriele BuondonnoManage base reference frameIn [appli_dcmZmpControl_estimator.py](https://gepgitlab.laas.fr/gbuondon/sot-talos-balance/blob/topic/dummywp/python/sot_talos_balance/test/appli_dcmZmpControl_estimator.py) (still on my fork) I am using a small entity which I called [St...In [appli_dcmZmpControl_estimator.py](https://gepgitlab.laas.fr/gbuondon/sot-talos-balance/blob/topic/dummywp/python/sot_talos_balance/test/appli_dcmZmpControl_estimator.py) (still on my fork) I am using a small entity which I called [StateTransformation](https://gepgitlab.laas.fr/gbuondon/sot-talos-balance/blob/topic/dummywp/src/state-transformation.cpp) to convert the estimator's output from the reference frame of the feet to the one of the SoT.
The entity takes as input the position of the feet center as expressed in the reference frame of the SoT and it multiplies the estimation result by this value.
It would be nice if this calculation were embedded inside the base estimator so that I can get rid of this tiny entity.
@fbailly would you agree?