Sensor Analysis¶
On this page information and knowledge about the robots are gathered, how they behave in different motion tasks.
Different Stiffness Values¶
Following are graphs for a simple stiffness test. The request for a joint was changed in one frame by a lot, which was repeated for different stiffness values. One graph each shows the joint positions and the other the change in position.
| Positions | Changes per Frame |
|---|---|
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
The position change for the hip, knee and ankle pitches for the time windows from frame 90 to 110 are shown below:
 |
 |
 |
|---|---|---|
Joint Play¶
As the robots get older and have been used more, the joints will gain more and more play. As far as we know, the position sensors can detect most of this play. But this does not help to let the joints execute the request perfectly. Following two examples are shown of joint play while walking for joints of the supporting foot. The dotted lines show the most expected position for the joint. We assume, that a joint can always hold its position, and if it has enough strength to move, it will follow the request. This means, that a measured position can differ by a huge amount relativ to the requested position, yet has actually no joint play. But if it moves too far or in the opposite direction, then it is moving in its joint play.
Knee Pitch Example¶
Here the knee is in the beginning part of the swing foot until about frame 12. Afterwards the foot becomes the support foot and the joint gets stuck. Interestingly at about frame 33 the request changes in direction of the measured position, which causes the joint to move by about the same amount, but shifted. The robot itself is in an state of being tilted a lot backwards. Here the knee is unable to move positive, because this would tilt the robot forward and therefore would need to work against the weight of the robot. But moving negativ tilts the robot even more backwards which the joint can easily do. The shift itself is assumed to be a result of the controllers of the motors. This effect can be reproduced on a new robot too, but less extreme because of the missing joint play.
Ankle Pitch Example¶
Here the ankle pitch becomes part of the support foot at the beginning. The robot is in a far forward tilted state. The request goes more negativ and the joint executes the movement change, but once again shifted by the already existing difference between the request and measured position. This effect can also be reproduced on a new robot, but also less extreme.
Note that this robot used for the grafics has about 5 degrees of play in the shown knee and about 4 degrees of play in the shown ankle. The differences of the positions and requests are mostly caused by this play, but also to some part because of the overall state of the robot, e.g. being tilted far back or forward. A robot with such high play is just a lot more likely to get into such state.
Hip Roll Example¶
Here, a common problem is shown while executing small side steps like 30 mm to the left. The leg of the walk direction (here the left leg) executes the requests mostly as expected. The other leg (here the right leg) shows large errors. In this example, the robot tried to adjust to the ball for a penalty shot out by walking sideways. Due to this execution error, the robot was just walking in place and did not reach the ball until a human intervened.
Note that this is only partially because of the worn out state of the robot. If the robot walks in the other direction, here to the right side, the right leg will now execute the request mostly as expected and the left leg will show larger errors.
From our testing so far, we observed the following helpful ideas:
- When the support foot switches, resetting the request closer to the measured position reduces the time the joint lags behind.
- Using a minimum velocity for the support foot side movement stabilizes the error and also slightly decreases it on average.
- Shifting the hip sideways in a way that the leg of the walk direction (e.g. the left leg when executing a left side step) executes most of the step change, does not improve the step execution.
Presentation¶
A presentation was done at the RoHOW 2022. The video can be found below.
Semi Automatic Joint Play Analysis¶
To get mostly accurate values in degree for the joint play for each joint, one just moves a joint by hand while it is in a stiff position. Wriggling the joint at a high enough frequency by hand is enough to subtract the measured minimum and maximum position of a given joint to determine the joint play.
To save time for this process, you can bring the robot into a standing position with the chest button and then connect to the robot with the simulator and execute the following command
call Calibrators/JointPlayAnalyzer
The robot is supposed to be hold upright in the air. The energy saving mode is deactivates, therefore the robot will heat up fast if simply placed on the ground. After executing the command the robot will move into a standing position.
To now get the joint play values, open a view of the representation JointPlayData (found in the Scene Graph data.motion.representation.JointPlayData). After the robot finished moving and is hold in the air execute the following command, to reset the detected play
dr module:JointPlayAnalyzer:reset
Now you can just wriggle on each joint by hand and the detected joint play is writting into the representation. For leg joints even new robots will have a very small amount of play of up to 0.3 degree for pitch joints. The hip pitches and rolls can reach up to 1 degree. The arms will have a lot more base joint play as well as the head pitch. An example of the procedure is shown below:
Note
The robot will not sit down after touching the head sensors. Also the joints will have a high stiffness, therefore be careful to not break something. To sit down the robot, you can deploy again, restart bhuman or shutdown the robot.
Detecting Broken Joints¶
A presentation was done at the RoHOW 2022. The video can be found below.
IMU Calibration¶
The imu of the robot contains values for the acceleration, the gyroscope and an estimation of the orientation of the robot. An estimation only based on the acceleration and gyro values result in a different orientation that of the imu.
To evaluate these differences we programmed our robots to stand and shift the soles, to slowly tilt the robots over the sole edges in all four directions. Based on these measurements we calculated the edges of the support polygon from the point of view of the robot, shown below.
These are quite large differences, resulting from orientation estimation errors, with the highest being about 4 degrees rotation error around the y-axis. We also tested to calibrate the acceleration and gyro values based on the orientation given by the imu. Meaning the difference between the orientation calculated by the acceleration values and the orientation given by the imu are used as an offset to rotate the imu values, before using them in our own estimation.
This fixed our observed errors in our support polygon experiment above and also removed some effects in our camera calibration process.
Note
This calibration process is done whenever the robot is not moving, because the imus have small drifts when the robots are turned on. So far most robots show a drift that result in errors of about 0.5 degrees and only one robot so far that showed errors of up to 2 degrees. The drifts seem to max out after about two hours, but can also reach this maximum drift after just 30 mins. This imu itself seems to calibrate this drift, but not perfectly.