-
Notifications
You must be signed in to change notification settings - Fork 18
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
Support Gazebo simulation embedded in the WB-Toolbox block, communicating over standard YARP C++ device interfaces #164
Comments
Ref : robotology/gazebo-yarp-plugins#391 (comment) .
Yes! Note that the thread spawning is actually the only way to use the Gazebo < 11 API (see https://bitbucket.org/osrf/gazebo/issues/2509/running-physics-world-step-wise). A good example (even better than Gazebo official examples, as it includes also the sensors) of how to run Gazebo < 11 in this way is https://github.com/kuka-isir/rtt_gazebo_embedded/blob/master/src/rtt_gazebo_embedded.cc#L552 (courtesy of good old @ahoarau )
I think that switching from the embedded Gazebo simulation to an external robot communicating over YARP ports (both gazebo standalone or real robot) should be as simple as switching from one Configuration block to another, but probably I am missing some technical aspect of the existing implementation.
Indeed! On the other hand, keeping the communication over YARP C++ interfaces (and hence using the existing WB-Toolbox blocks) ensure that we maintain compatibility with all the existing controllers and we maintain easy interoperability with communicating with a robot over the YARP network. Furthermore, it can also simplify exploiting all the core of the machine. |
A tricky aspect is how to provide visualization capabilities (assuming Gazebo < 11 in the following). As in the proposed configuration WB-Toolbox will run a normal Gazebo server (code equivalent to This manual step can be avoided if we add the option for spawning automatically (and closing) the gzclient process from the WB-Toolbox itself, using one of the existing libraries to spawn process in a platform-independent way:
If the gzclient is launched by the WB-Toolbox, it is also possible to specify a custom |
If YARP ports are involved yes, it would be straightforward. Though, I thought that in the simulated case you proposed, WB-Toolbox would attach directly to the interfaces, without the need of wrappers. Actually, all the blocks that access robot resources pass through the
Probably the best architecture would be transforming the More in details, the implementation of the gazebo-based @traversaro Would this be feasible? I never looked how to execute gazebo < 11 in this way. |
Yes, this is exactly what I meant. If I understand correctly, once this is implemented, switching between Gazebo-embedded and YARP-ports will be just changing the configuration block (or enabling/disabling two different configuration). The implementation may be complex, but once implemented the user experience will be quite straightforward, or I am missing something? |
Yes! However just having two classes will have a lot of duplication in the iDynTree-related RobotInterface's classes, so it coould make sense to keep them in a third class, or something like that.
Yes! However, the co-simulation with an external Gazebo can still have a lot of use cases, so I would not remove it. |
Yet it would be straightforward.
I would keep a single Configuration block, and playing around with showing / hiding elements in the Simulink mask. About the
Sure! |
I think that the refactor of |
I suspect that in the use case you described we might have the need to pass through a singleton in order to pass those pointers to the More in detail, what I am asking myself is how to pass these pointers from the |
I tought that we had some freedom on how the autogenerated class is generated (some template, etc etc) but probably I was just confused. Indeed, the easiest solution (if the generated parameters API is not working as expected, see robotology/blockfactory#42 (comment)) would be to set them in some sort of singleton, possibly using some kind of identifier string for the autogenerated model, if we eventually want to support to have multiple different autogenerated models inside the same yarprobotinterface. |
For sure we can add what we want in the cpp file. I am pretty sure we can also add classes and structs in the header of the autogenerated source, but I never did it (only headers are included right now). However, I never read anything about the possibility to operate on the declaration of the autogenerated class. Alternatively to the singleton, if we can add our own structs in the headers where we might store there the pointers to the interfaces, but this would mean that the TLC provided by blockfactory will not be anymore general. |
Since this issue is being linked quite a lot around our repos, it is worth adding a link to the |
Interesting example of a similar approach by the Yonohub company: https://towardsdatascience.com/yonohub-autonomous-vehicles-using-blocks-ef4a1838d92c . |
Something that we may want to evaluate for linking Gazebo libraries with Matlab/Simulink, is that apparently Matlab ships its own vendored Protobuf, that could create problems if it is not the same version of the system's Protobuf used by Gazebo. |
Summary
Support Gazebo simulation embedded in the WB-Toolbox block, communicating over standard YARP C++ device interfaces.
Motivation
Users will just need to press play to launch a simulation, without the need to launch Gazebo separately. In particular, I remember seeing once how @FabioBergonti workflow was extremely complicated due to this.
Additional context
From the user point of view, I think that feature can be implemented by creating a new type of "configuration" block, that takes in input all the usual parameters, with these differences:
robotName
(that is actually the port prefix) and thecontrolBoardsNames
. This parameters will be replaced with some parameters necessary to get the correct devices from the "device database" available in theGazeboYarpPlugins::Handler
singleton class: https://github.com/robotology/gazebo-yarp-plugins/blob/master/libraries/singleton/include/GazeboYarpPlugins/Handler.hh#L117 (device name should be sufficient, but this probably will need to be revised to support multi robot)..world
file to specify the scenario to simulate. The.world
could probably also exploit the recent features added in gazebo-yarp-plugins to ensure flexible composition of yarp-based models.From the implementation point of view, it is probably necessary to refactor the
wbt::RobotInterface
and thewbt::Configuration
.The text was updated successfully, but these errors were encountered: