sot-talos-balance issueshttps://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues2019-05-15T14:43:06Zhttps://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/11Additional bibliography2018-12-04T17:18:21ZNicolas MansardAdditional bibliographyI suggest that the biblio of the project is added in a bib/ directory of the repo.
This task is to identify additional papers that should be red following Caron 2018. Consider in particular recent papers by Honda (cited by Caron) and pa...I suggest that the biblio of the project is added in a bib/ directory of the repo.
This task is to identify additional papers that should be red following Caron 2018. Consider in particular recent papers by Honda (cited by Caron) and paper by Flayol&DelPrete.https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/22Admittance control of the ankle2019-07-09T15:14:46ZNicolas MansardAdmittance control of the ankleTo be tested on the robot. If testing in the air, add a switch to deactivate when normal forces too low.To be tested on the robot. If testing in the air, add a switch to deactivate when normal forces too low.Admittance controlhttps://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/21Admittance control of the COM2019-04-10T16:02:42ZNicolas MansardAdmittance control of the COMAdmittance controlGabriele BuondonnoGabriele Buondonnohttps://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/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/53Calibrating force sensors2019-04-18T07:13:00ZGabriele BuondonnoCalibrating force sensorsBy suspending the robot in the air and measuring output of the foot force sensors, a bias of about 5 kg was highlighted on at least one of them.
Experiments have not shown any sensible temperature drift, but this remains to be investiga...By suspending the robot in the air and measuring output of the foot force sensors, a bias of about 5 kg was highlighted on at least one of them.
Experiments have not shown any sensible temperature drift, but this remains to be investigated more rigorously.
@tflayols and @fbailly are now running an experimental campaign on the robot to gather as many data as possible, in order to design a calibration routine which will be automatically run at the robot start.
This might interest @frisbourg too for the end-effector admittance.https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/2Capture a dataset from robot IMU + mocap2018-12-04T17:20:07ZNicolas MansardCapture a dataset from robot IMU + mocapSee #1. This is an evolution of #1, capturing a similar IMU sequence but using the MoCap to have a ground truth. The mocap might be @ GBauzil of Creps.See #1. This is an evolution of #1, capturing a similar IMU sequence but using the MoCap to have a ground truth. The mocap might be @ GBauzil of Creps.Basis estimation from IMU and contacthttps://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/70Check force threshold in ZMP estimator2019-04-18T17:46:26ZFrançois BaillyCheck force threshold in ZMP estimatorWhen we lifted the robot in the air today, the emergency stop signal did not triggered. We should rise up the value of the threshold to overcome this issue.When we lifted the robot in the air today, the emergency stop signal did not triggered. We should rise up the value of the threshold to overcome this issue.https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/26Decided/calibrate flexibility at the hip on Pyrene2021-09-06T08:32:34ZNicolas MansardDecided/calibrate flexibility at the hip on PyreneThis is a prospective task. Some flex values have to be put in the kinematic model for @tflayols estimator to work. Let's decide which values.This is a prospective task. Some flex values have to be put in the kinematic model for @tflayols estimator to work. Let's decide which values.Basis estimation from IMU and contacthttps://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/12Documentation2019-03-19T09:41:50ZNicolas MansardDocumentationHow should we document the work of the group? In the wiki of the repo?How should we document the work of the group? In the wiki of the repo?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/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/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/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/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/63Force distribution2019-07-08T17:56:33ZGabriele BuondonnoForce distributionExcept for #61, the CoM admittance control is basically done. We can start thinking about the force distribution.Except for #61, the CoM admittance control is basically done. We can start thinking about the force distribution.Gabriele BuondonnoGabriele Buondonnohttps://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/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/69Load parameters using YAML/rosparam2019-05-15T14:43:53ZGabriele BuondonnoLoad parameters using YAML/rosparamRight now, all parameters, including robot parameters, calibration parameters, control parameters, are either hard-coded inside the test files or written in the configuration files in [python/sot_talos_balance/talos](https://gepgitlab.la...Right now, all parameters, including robot parameters, calibration parameters, control parameters, are either hard-coded inside the test files or written in the configuration files in [python/sot_talos_balance/talos](https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/tree/devel/python/sot_talos_balance/talos), which are then imported by the test files, resulting in something that is centralized, but still somewhat hard-coded.
I believe this approach is not the best. Parameters should be stored inside YAML files, which can then be loaded runtime using rosparam. This is especially true for control parameters. We know very well that the parameters in simulation might greatly differ from those on the real robot. We don't want our code to be continuously changing just because one is switching from the simulation to the robot and vice-versa!
I'll try to see what can be done.