-
Notifications
You must be signed in to change notification settings - Fork 33
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
Define a utility class to communicate with Gazebo in a test #114
Comments
If you intend to communicate with the Gazebo simulation just via YARP ports, then you have two possible options: either you launch For option A, I think it is may worth to check libraries that simplify the spawn of new process, @diegoferigo in the past used For option B, beside the pointers on how to build a custom main for Gazebo that I provided in the other comments (i.e. https://github.com/osrf/gazebo/blob/6fd426b3949c4ca73fa126cde68f5cc4a59522eb/examples/stand_alone/custom_main/custom_main.cc/custom_main.cc?at=default, gazebosim/gazebo-classic#1145 and https://github.com/kuka-isir/rtt_gazebo_embedded/blob/master/src/rtt_gazebo_embedded.cc) another interesting piece of software is the one provided in the Gazebo's header |
I want to drop some pointers here of what I discussed yesterday f2f with @S-Dafarra, not sure if this is the best place. The exploration of the RL team with Ignition Gazebo are being quite successful and we managed to 1) simplify the installation of our sw stack and 2) streamline its packaging and distribution. The C++ library that powers all the machinery is called ScenarI/O, and its Gazebo backend provides something very similar to what you're accomplishing with Under the assumption that BLF has 1) python bindings #53 and 2) has no middleware involved, it would be very easy to write unit testing from Python. You can have a look at Note that if you prefer avoiding Python, everything could be done also from C++. However, being primarily a C++ developer, I much appreciate the fast development cycle that Python offers and the flexibility of the pytest suite. Note also that this approach would ensure reproducibility, and even better, offers a single-process approach that makes CI integration much easier. |
Regarding option A, since we will focus mainly on Ubuntu for the time being, we were also considering some simple bash scripts to launch Gazebo. @GiulioRomualdi did a similar thing to launch bash scripts as a tests in CMake for the iFeel GUI. For option B instead, will we be able to load the |
As long as the directory containing the YARP plugins are correctly passed to |
Indeed, the
Maybe it is possible to copy |
Indeed, it may be possible. I don't really remember why I thought it was coupled with gtest so much. |
Probably it is because I was writing test to be parametric in the physic engine, and so I used https://github.com/osrf/gazebo/blob/6fd426b3949c4ca73fa126cde68f5cc4a59522eb/gazebo/test/helper_physics_generator.hh that indeed is coupled with gtest. |
Keeping in mind all the above discussion, we chose the following route as described,
Instead, the Gazebo utility class might use the
But here my question is that since the Gazebo instance would already be loaded by the bash script, we will not have control over such an instance and I don't understand how to establish a communication with the running Gazebo instance using the Since with |
This was one of the open points. If Gazebo runs as a separate process, it is not possible to use the APIs. To be honest, I am not aware on how to access the Gazebo topics once this is running, nor which kind of information you can retrieve. In any case, probably we will need to access at least the base position. Then, we can test the interface when the robot is already in a known position. After we have the |
I can experiment with the Transport API, if we can agree it might be one possible right way to go. However, in this case, if I am right, we would rely on a thread based process (where each subscriber might spawn a thread for a relevant callback function to update the buffers for the topic we subscribe to). This might be a source of non-determinism. |
Anyways, now after the discussion we had and reading through all the above pointers, I think I understand what needs to be done. I might have to do some active experimentation to understand the best way forward, indeed. |
No, actually now I remember: in https://github.com/osrf/gazebo/blob/6fd426b3949c4ca73fa126cde68f5cc4a59522eb/gazebo/test/ServerFixture.hh#L66 the |
Description to be updated.
Copying relevant information gathered during the t2t meeting with @dic-iit/telexistence
The text was updated successfully, but these errors were encountered: