sot-talos-balance issueshttps://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues2018-12-04T17:20:07Zhttps://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/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/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/17Velocity-driven servo2020-11-13T19:38:43ZNicolas MansardVelocity-driven servoThis is a prospective task. We might want to have a velocity-driven control of Pyrene, and not a position+integration-of-velocity as on HRP-2. Let's first play with the actual position servo before really investigating this issue.This is a prospective task. We might want to have a velocity-driven control of Pyrene, and not a position+integration-of-velocity as on HRP-2. Let's first play with the actual position servo before really investigating this issue.https://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/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/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/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/61Velocity feedback2019-04-11T15:59:29ZGabriele BuondonnoVelocity feedbackIt seems velocity feedback is problematic, at least in simulation. This should be investigated. Also, we need to check whether we observe the same bad behaviour on the real robot (according to Hilario we should not)It seems velocity feedback is problematic, at least in simulation. This should be investigated. Also, we need to check whether we observe the same bad behaviour on the real robot (according to Hilario we should not)https://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/65QP solver2019-04-05T16:23:25ZGabriele BuondonnoQP solverIn the force distribution, a QP problem needs to be solved, which raises the question of which library to use.
So far, everybody has been copying code from one repo to the other. The are [talks](https://github.com/stack-of-tasks/tsid/is...In the force distribution, a QP problem needs to be solved, which raises the question of which library to use.
So far, everybody has been copying code from one repo to the other. The are [talks](https://github.com/stack-of-tasks/tsid/issues/9) in TSID to externalize it, but so far nothing has been done.
I really do not want to copy-paste a QP solver routine inside sot-talos-balance. We should rely on an external library for that. This is my belief. And I would like not to depend on TSID.
I started with eigen-quadprog, taken from [JRL's repo](https://github.com/jrl-umi3218/eigen-quadprog). It is available on robotpkg's apt repositories, that's how I installed it. It worked well on a [simple test](https://gepgitlab.laas.fr/gbuondon/quadprog-test) and it seems to be doing fine in the SoT, given a very simple program. However, many people have raised concerns on this repo. It is based on C++ code which was auto-generated from Fortran. @ostasse explicitly warned me against using it. The repo was made 4 years ago with 3 commits and has never been touched since then. It should probably not be trusted.
Another option is eigen-qld, also [from JRL](https://github.com/jrl-umi3218/eigen-qld). This is not on robotpkg, so it has to be installed from source. I couldn't compile the Python bindings, so I disabled them, we don't need them. The interface is more or less the same as eigen-quadprog. I also made a [test](https://gepgitlab.laas.fr/gbuondon/qld-test), it seems ok. eigen-qld repo is also based on auto-generated code. However, the repo seems to be much more active than eigen-quadprog. We can probably trust it more.
Caron is currently using eigen-lssol, but it is not an option for us, because it relies on LSSOL, which is proprietary and needs a licence (also, the eigen-lssol itself is not publicly available and we should ask it from them). He is planning to switch to eigen-qld.
Finally, another possibility is [qpOASES](https://projects.coin-or.org/qpOASES), but I haven't taken a look at it.
Rebus sic stantibus, I think I'll switch to eigen-qld and stick to it. @ostasse what do you think?https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/-/issues/67Validate base estimator using the mocap2019-07-10T15:12:30ZGabriele BuondonnoValidate base estimator using the mocapThe base estimator is ready. We just need to validate it through the mocap. I know @fbailly and @tflayols have prepared the necessary stuff required to interact properly with the mocap (and they made a really cool demo out of it!). So, I...The base estimator is ready. We just need to validate it through the mocap. I know @fbailly and @tflayols have prepared the necessary stuff required to interact properly with the mocap (and they made a really cool demo out of it!). So, I think not much coding work is required.https://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.https://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/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?https://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/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/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/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/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?