-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[iCubGenova09] Increase the speed of the low level (WBD 500Hz) #20
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for the PR!
The comments are related to a set of changes that in my opinion is not straightforward. If you happen to have some cross-reference that indicates why those changes are needed, it could be useful for future reference.
Also, did you notice any error or warning in the logger regarding timeouts? |
I'm going to check it on the robot right now |
763cff1
to
00b7c42
Compare
@S-Dafarra @traversaro I updated the comment #20 (comment) |
d6fcda1
to
6ec6b8a
Compare
a65de00
to
e3aec73
Compare
6ec6b8a
to
bb8074e
Compare
bb8074e
to
e2830ba
Compare
@pattacini could we ask for your support to make sure that these modifications are:
|
CC @traversaro |
Hi @S-Dafarra I'll be checking that tomorrow with the fixers. |
@@ -43,7 +43,7 @@ | |||
</group> | |||
|
|||
<group name="SETTINGS"> | |||
<param name="acquisitionRate"> 10 </param> | |||
<param name="acquisitionRate"> 5 </param> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I got it right, it seems that 10
is the fastest allowed rate as per https://github.com/robotology/icub-main/blob/master/src/libraries/icubmod/embObjInertials/embObjInertials.cpp#L527-L538.
Have you seen the following warning message popping up?
embObjInertials::sendConfig2MTBboards() has detected a wrong acquisition rate =...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this device is of type embObjIMU
, so I am not sure if any limit like that exists.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I got it right, it seems that
10
is the fastest allowed rate as per https://github.com/robotology/icub-main/blob/master/src/libraries/icubmod/embObjInertials/embObjInertials.cpp#L527-L538.Have you seen the following warning message popping up?
embObjInertials::sendConfig2MTBboards() has detected a wrong acquisition rate =...
The 100 Hz frequency (acquisitionRate = 10 ms) is the maximum frequency that we can squeeze from the IMU Bosch BNO055. And that is due to HW limitation, in particular to the way the chip replies over the used I2C bus. We thoroughly explored this limitation some time ago.
So, we should correct the value to be 10.
On the other hand, in here the intention is to
- increasing the frequency of IMUs to 100Hz
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this device is of type embObjIMU, so I am not sure if any limit like that exists.
Regarding this, the function in question is then at https://github.com/robotology/icub-main/blob/26c74355c9d6463762352f41f8f1a1df593844ca/src/libraries/icubmod/embObjIMU/eo_imu_privData.cpp#L314-L340.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this device is of type
embObjIMU
, so I am not sure if any limit like that exists.
@traversaro: thanks for it. I checked and device embObjIMU
does not check vs incorrect values of acquisitionRate
as the original device embObjInertials
did. Maybe in the migration towards the new device something was missed.
But the FW indeed does the check and clips values in range [5, 200] ms. The lower possible value is 5 because in some cases (e.g., when the board asks via I2C only one or two values such accel and gyro) 5 ms can be OK. But again, 10 ms is the recommended lower value that we should use. Also because the fusion algorithm inside the BNO055 chip produces new values only every 10 ms.
@@ -3,7 +3,7 @@ | |||
|
|||
|
|||
<device xmlns:xi="http://www.w3.org/2001/XInclude" name="head-imuFilter" type="imuFilter"> | |||
<param name="period"> 20 </param> | |||
<param name="period"> 2 </param> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The hardware
section instructs boards to retrieve new IMU values every 10 ms.
So, the best period of the wrapper is 10 ms. To have 2 ms is not wrong, but it may stress the system more than we need.
This comment applies to all the wrappers inside folder inertials
.
Thank you @marcoaccame! I'm going to apply your suggestions See e2201aa and 1ce2566 |
OK, now the PR now seems fine by me. |
I will squash all the commits and I will test it on the robot. If everything goes smooth we can merge it |
1ce2566
to
8b98ecd
Compare
- increasing the frequency of IMUs to 100Hz - all MAS interfaces for the FTs go at 500Hz - all control boards go at 500Hz
8b98ecd
to
274612c
Compare
This PR decreases the period of the WBD from 0.01 s to 0.002s. The PR also increases the rate of the hardware devices and the network wrapper.
This comment will first details the profiling analysis and then I will analyze each parameter that I modified
Time profiling
WBD profiling
Before entering into the details of the PR I would like to show you the time profiling result of WBD. The analysis has been performed by exploiting the timers I implemented in robotology/whole-body-estimators#142
The following table contains the average time (the average time window is equal to 1 minute). The labels
publish
computed forces
etc. refer to the different sections in the main loop in robotology/whole-body-estimators@d49bdd1 The labelall
indicates the time spent to perform the entire loop.Accordingly to the profiling, WBD is able to handle this frequency 🚀
Board messages
The boards stream sometimes the following warning. However, the robot seems working as expected.
yarprobotinterface.txt contains the log of the yarprobotinterface. Perhaps @traversaro or @S-Dafarra have some hints.
PR analysis
iCubGenova09/estimators/wholebodydynamics.xml
<param name="devicePeriodInSeconds">0.002</param>
increase the frequency of wbd from the default value 100Hz to 500HziCubGenova09/hardware/FT/left_arm-eb1-j0_1-strain.xml
tfPeriod
from 10 ms to 2ms (500Hz)iCubGenova09/hardware/electronics/face-eb23-j2_5-eln.xml
TXrateOfRegularROPs
from 3 (or 5) to 2 (500Hz here you can find some documentation)iCubGenova09/hardware/inertials/head-inertial.xml
acquisitionRate
from 10 to 5 (200Hz)iCubGenova09/hardware/inertials/left_arm-eb1-IMU.xml
acquisitionRate
from 50 to 5 (200Hz). I noticed that all the inertials attached to the FT were running at 20Hz before this PRiCubGenova09/wrappers/FT/left_arm-FT_wrapper.xml
period
from 10 ms to 2ms (500Hz)iCubGenova09/wrappers/inertials/left_foot-IMU_wrapper.xml
period
from 10 ms to 2ms (500Hz)iCubGenova09/wrappers/motorControl/left_arm-mc_wrapper.xml
period
from 0.02 s to 0.002s (500Hz). It is important to notice that0.02 s
is the default value of thecontrolBoard_nws_yarp
device so before this PR the rate was 50Hz.This substitutes #10