Heat Adjustment¶
As the robots walk around, get up and play soccer, one must handle the warming up of the motors. On one hand at different temperatures the controllers of the motors will reduce the stiffness automatically and if ignored will reduce the stiffness so much that doing anything apart from standing becomes impossible. On the other hand if ignored even further one may risk damage to the motors.
A normal approach to handle this problem is to let the robots just stand more around instead of walking all the time. Berlin United 1 already noticed that this is not sufficient enough as the robots remain in a state of permanent tension. We looked into it too and noticed that even though the differences of the requested joint positions and measured ones can be very low or even measured to be 0, the currents on the motors can exceed 1000 mA.
The threshold that Berlin United found was that currents of more than 300 mA heat up the motors. Inspired by their solution we implemented our own, which takes the same ideas but with some more over-engineering.
Structure¶
The implementation is done in the module EnergySavingProvider
. The idea is that other modules, which generate the request for the joints, the so called representation JointRequest
, can use functions implemented by EnergySavingProvider
to adjust the JointRequest
by small amounts to prevent a warming up of the motors or even achieve a cooling down effect.
The main function applyHeatAdjustment()
implements this logic which is shown below. Based on the last state in the previous motion frame the function knows if the energy saving mode was active or not. If it was not then (in ::off
) initial offsets are determined for the leg joints IF the robot is in the normal standing posture. Afterwards for up to 100 ms is waited (in ::waiting
). Then once every 0.5 seconds (in ::working
) the leg joint with the highest current and all arm joints with a current of above 300 mA are adjusted. If the robot is NOT
in the normal standing posture then all leg joints with a current of above 300 mA are adjusted.
In case the robot is picked up, placed back to the ground, the module calling the function no longer wants to apply a heat adjustment or the current offsets grew too large a reset is started. Here (in ::resetState
) all offsets are interpolated back to 0 over a short time. Afterwards the heat adjustment can start once again.
Note
The module EnergySavingProvider
implements two different behaviors, depending on the parameter accuratePositions
. If accuratePositions=false
is set the energy saving mode is used. Otherwise the JointRequest
is manipulated in such a way that the measured positions result in the original requested ones. This is used for only special use cases and not for playing soccer, as the joints will heat up even faster.
applyJointEnergySaving¶
The implementation of the adjustment works as follows. The adjustment for a specific joint is only updated if the current of it is above a given threshold. If the adjustment for the leg joint is below 1.5 degree then an adjustment is done if the current is above 100 mA. Otherwise 300 mA is used as a threshold. For arm joints 30 mA is always used.
If the threshold is exceeded, than a counter is increased for this joint. It counts how often this specific joint was adjusted. If the counter does not exceed a given threshold (stepsBeforeEmergencyStep
, currently set to 10) then the adjustment is updated as follows.
If the difference of the last requested and measured position is bigger than 0.2 degrees (0.458366 degrees for arms) then this value is used as an additional adjustment. Otherwise use 0.0286479 degrees as an adjustment value. Note that this value is a lot smaller than the actually min step size, which is around 0.08 degrees.
In the case the counter exceeded the given threshold then the max step size is used too, even if the difference between the requested and measured position is near 0.
With this logic we achieve quite fast a state where all leg joints measure below 300 mA. On worn-out robots we once had the problem that this was not enough and mostly the knee joints kept heating up. With those emergency jumps and the initial offset calculation we can let any robot stand around without heating up. Also with those very small steps of 0.0286479 we are able to achieve below 50 mA for most if not all legs joints after a few seconds of standing.
The effect on the currents is shown in the graphic below. The robot was walking until around the time mark 400 and transitioned into the high stand posture (stretched out knees). The currents could be quickly reduced until the robot started walking again at around the time mark 1400 (first transitioning into the normal walk height and then starting to walk at around 1900). At the time mark around 2300 another stand phase (without stretched out knees) starts and reduces quickly all currents below the 300 mA mark and afterwards even further below 100 mA.
Advantages¶
With our current solution we can ensure that our goalie and most of the time our defenders too are only slightly heated up after a half time, both being in range of between 35 and 45 degrees Celsius. Normally our goalie only gained a few degrees Celsius in temperature, even though the robot was standing 10 minutes straight in the normal stand posture, where the knee pitches are Not stretched out.
This allows us to switch the robots in their position in a half time pause, e.g. switching a field player with the goalie and defenders with forward players. As a result only a few robots are barely reaching a heating state, e.g. a state in which the controllers are reducing the stiffnesses of the motors. For playoff games most robots will reach the heating state, as those games take a few minutes longer. But even then we had no problems so far with robots not being able to play anymore.
Compared to years before we used this heat adjustment, we had multiple games in the past where robots needed to be picked up in the second half because the motors heated up too much and the robots kept falling. We even had games where our goalie, which had nothing to do apart from standing around, already reached a heat state after only 3 minutes in the first half.
Other Tests¶
We also experimented with a heat adjustment while walking. So far no changes satisfied our needs.
Changing stiffness based on the CoM¶
Based on the center of mass (CoM) we tried to interpolate the stiffness to a lower value. If the robot is tilted far forward, the ankle pitch can not move anyway. Therefore to reduce the current and the risk of breaking, we tried to interpolate the stiffness down from 100 to 60. Apart from the fact that the robots walked significantly worse, it also broke multiple ankle pitches and the currents on the motor were higher.
We tested the same for the knee pitch, but for CoM positions far backwards. This also only made the walking worse and increased the current on the motor.
Shifting the Torso¶
Based on the joint with the highest temperatur from the knee and ankle pitches, we tried to shift the torso forward while walking, up to 6 mm. We tried this changes in a few testgames and also in the first few RoboCup 2024 games. We could not detect a noticeable change in the temperatures. Therefore to not make the walking implementation even more complex, we removed this change once again.
Lower stiffness¶
We did a few tests for the knee pitch, to always use 75 instead of 100 stiffness. This currents are noticeable reduced during the stressed situations. Further testing needs to be done.
Noticed effects¶
The most prominent times that the knee and ankle pitches have high current values, is during specific times for the supporting leg. For the knee it is when the robot is tilting backwards. Stopping the requested knee position change does not change the current, but using a lower stiffness does. For the ankle pitch it seems like when the motor needs to slow down the position change.
Further tests needs to be done here. But we expect that without some domain knowledge about how the motors behave we currently used walk can not be improvement to heat up less fast.
-
Heinrich Mellmann - Berlin United - Nao Team Humboldt Team Report 2016 , Adaptive Systeme, Institut für Informatik, Humboldt-Universität zu Berlin, 2016 ↩