loco-3d / torque-control Goto Github PK

A critical information during development is the computational time. It is now measured in the graph for different entities and for particular code exécution via the profiler. It is also computed by the real time loop and stats are displays one's a while in std output.

It would be good to have it as a signal for online plotting and allow future rosbag records investigation.
A dedicated entity could expose the profiler stats as signals.

To be complete, the realtime loop should send to the SoT its own execution time, and the communication time with the motor and sensors. This could be seen as a regular measurement and be exposed as signals in the device.

We have problems with some joints of the robots, and it would be more than useful to have spare part ready for harmonic drive reducers. We believe performances of force tracking can be greatly improved if this joints reducers are fixed.

Is there a generic HD that can be adapted to HRP-2 ?
Is it possible to get some HD from japan ?

We need a working simulation of the robot with the ankles flexibility to speed up the controller development. Actually openHRP is behaving strangely and become unstable after some time.

We need to investigate this issues.

A calibration of the F/T sensors in HRP-2's ankles may be beneficial, especially in the estimation of the ZMP, which is crucial for balancing and walking on flat ground.

The normal force calibration could also be achieved by attaching a known load to the foot. Then, by applying forces on the four corners of the foot we could easily calibrate the tangential moments.

Currently, we manage to get in single support by filtering a lot the forces given to the force tracker. We know that this force should be filtered less for the base estimation.

The next test to do is to plug a less filtered forces to base-estimator and to compare the behavior.

We need to test and tune the controller to get an acceptable motion tracking of the flying foot. We may have to choose different gains for flying foot and for support foot. In that case we should allow the controller to take gains as signal from a plan trajectory, or to generate gains values from the contact detection.

On HRP-2 we are currently using an observer (see sot-state-observation) to estimate the state of the two springs located in the robot's ankles. In turns, this allows us to estimate the pose (position + orientation) of the robot's base. In order to validate the output of this observer we could compare the position of the center of pressure (computed with the 6-axis force/torque sensors in HRP-2's feet) with the projection on the ground of the position of the center of mass of the robot. When the robot is in static equilibrium these two should be at the same point.

Of course a lot of other factors could negatively affect the outcome of the test, such as errors in the inertial parameters or in the kinematic model of the robot. A better way to validate the observer could be to use the motion-capture system, but that would require more work.

At the moment the control loop on HRP-2 runs at 400 Hz, whereas we would like to reach 1 kHz especially in order to improve velocity estimation through finite differences. Most of the time is taking by these three parts:

1. about 0.7 ms: flexibility observer (see sot-state-observation
2. about 0.6 ms: QP for inverse dynamics using eiquadprog (see invdyn)
3. about 0.5 ms: low-level sensor reading and motor commands

We believe that for all these three pieces of code there is room for improving performance, so that we could increase the control frequency.

To carry out experiments on the robot we are currently relying we connect to the python interpreter (running on the robot) through a rosservice, which gives us a python console, but without auto-completion. This makes the experiments quite slow because we struggle to remember the names of the signals and the commands of the different entities, so we have constantly to use the methods displaySignals and commands to check the names.

Here are a few features for a GUI to use with dynamic graph, which could be an extension of rqt_dynamic_graph:

• python console with auto-completion.
• see a list of all available entities
• clicking on an entity shows the list of its signals (divided by input, output) and commands
• clicking on a signal shows its value and time
• clicking on a signal opens a plot for that signal
• clicking on a signal creates a ROS topic that we can later use for plotting with rqt_plot
• clicking on a signal we can set its new value using the smooth_set_signal function
• clicking on a command shows its documentation
• show a graph representing the entities and their connections that the user can rearrange (for the graph we could start from rqt_graph)
• show the viewer with the robot at its current state
• show the current and torque percentage (w.r.t. their max) at each joint
• buttons to start/stop dynamic graph and the low-level motor/sensor access

For the list of entities, signals and commands, we could start from the layout of rqt_logger_level, which you can see here.

We believe the CoM estimation could be improved using force sensors. We detect differences of about 1cm from CoP and CoM in static. It is to note that this errors depends on the posture, so it may be related to wrong mass distribution model. We also detect a whole body mass difference between model and measurement. Another possible problem is a wrong calibration of the feet force-torque sensor (related to #3)

A result of a non coherent CoM to CoP quantities is a conflict in the controller making us have to prioritize with a lot of caution the Force and CoM tracking task weight.