Changes in accessing inertial data #360
Nicogene
started this conversation in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi @robotology/all-robotology-developers ,
This issue is to inform about the new "canonical" way for accessing the inertial data.
Preface
robotology/yarp#1586 introduced multiple analog sensors interfaces and related devices. In particular the devices are:
multipleanalogsensorsserver
multipleanalogsensorsclient
multipleanalogsensorsremapper
In a few words, they have been designed for exposing and accessing the multiple analog sensors over a network, and for combining multiple devices in a single device (remapper).
In the past the inertial sensors (e.g the IMU in the head) was wrapped by the
ServerInertial
, that publish the data as a Vector of 12 elements:One of the major headache was to remember every time which was the indices of the vector corresponding to a certain type of data. Instead, the multipleanalogsensors devices allow to retrieve the specific type of data the client code needed.
Example of usage in user code
To retrieve the inertial data through this new family of devices it is needed to instantiate in the code a
Polydriver
of typemultipleanalogsensorsclient
and then call theview
of the interfaces regarding the inertial data you need, e.g.:This example accesses only to the gyro and accelerometer data, but there are other interfaces to retrieve also the euler angles, magnetometer etc (see here)
Note that for the
remote
parameter of themultipleanalogsensorsclient
you have to specify the same name used aslocal
parameter in themultipleanalogsensorsserver
that exposes the inertial dataChanges in icub-related software
devel
branches.This new paradigm has been adopted in
iKinGazeCtrl
andimuFilter
.iKinGazeCtrl
The
iKinGazeCtrl
if theimu::mode
parameter is set toon
, tries by default to attach themultipleanalogsensorsclient
to themultipleanalogsensorsserver
with the prefix port name/icub/head/inertials
, according to the convention used for the imu of other parts.In alternative, as before, it is possible to specify the
imu::source_port_name
to attach to a different publisher of inertial data.For example the
source_port_name
of theimuFilter
is simply/imuFilter
.imuFilter
For its nature of "man-in-the-middle" that takes the data, filter it, and then publish them filtered, to adopt this new paradigm it has been converted as device driver (robotology/icub-main@9a46fb2).
In this comment is explained how to run it through
yarprobotinterface
through theyarpdev
executable.Changes in robots-configuration
This PR added the required changes in the xml files in order to wrap the inertial sensors with the
multipleanalogsensors
and run the new version ofimuFilter
.How this impacts my work
Actually the "old"
/icub/inertial
of theServerInertial
is still exposed, then your application can still get the imu data in the old way(see http://wiki.icub.org/wiki/Inertial_Sensor).The only problem you may have is if you update
robots-configuration
and then noticub-main
,yarprobotinterface
would fail since it has not theimuFilter
device. To solve this, simply update alsoicub-main
.Moreover
imuFilter
is not anymore a module, and it is opened by theyarprobotinterface
, then it may be possible that you have to remove it from the xml files of your yarpmanager applications.For any further questions or doubts, feel free to contact me or the author of the
MultipleAnalogSensorsInterfaces
, @traversaro .Beta Was this translation helpful? Give feedback.
All reactions