Code Monkey home page Code Monkey logo

Comments (5)

barbalberto avatar barbalberto commented on June 19, 2024

Note:
The module 3DM_GX3 can be used as a reference. It is the device used to read data from the real IMU sensor on coman.
The moudle is in iCub/main/src/libraries/icubmod/imu3dm_gx3

the IGenericSensor interface has to be implemented and the appropriate wrapper to use is the ServerInertial, which is into yarp/libYARP_dev/include/yarp/dev/ServerInertial.h

from gazebo-yarp-plugins.

traversaro avatar traversaro commented on June 19, 2024

I am trying to tackle this issue, but apparently there is no way to obtain the parent ModelPtr from the SensorPtr provided as an argument of the Sensor Plugin (at least I was not able to find a way: http://gazebosim.org/api/2.0.0/classgazebo_1_1sensors_1_1Sensor.html ). So it is not possible to use directly the singleton handler.

Do you think it could make sense to extend the handler to handle also sensor pointers (by using as a key the scoped name of the sensor, to avoid name clashes between robots with sensor with the same name)?
This could potentially mean a lot more values in the handler, but as long as the handler is used only in initialization I don't think this would be a big issue.

from gazebo-yarp-plugins.

traversaro avatar traversaro commented on June 19, 2024

I add a little clarification because I am afraid I was not clear: my idea is to use the runtime scoped name of the sensor (obtained by GetScopedName()) as a key for the handler, and to pass this key to the driver by adding it at runtime to the properties that are passed to the driver, without any sensor name/key hardcoded in the configuration files.

from gazebo-yarp-plugins.

traversaro avatar traversaro commented on June 19, 2024

I have implemented the proposed solution in commit d53d8ea of development branch. I am not really sure about the solution of using the ScopedName of the sensor as the key for the singleton because I find (but It can be a wrong assumption on my side) that the traditional spirit of yarp device configuration file is that everything needed to create a device (possibly using also yarpdev utility) is found in the relative .ini file.
On the other hand I think every gazebo yarp device will always be created explicitly by the relative gazebo yarp plugin (correct me if I am wrong) so having an "incomplete" configuration file is not an issue.

from gazebo-yarp-plugins.

traversaro avatar traversaro commented on June 19, 2024

Done in a31320c

from gazebo-yarp-plugins.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.