Gazebo on Windows: conda-forge installation #2899
Comments
|
My testing of the superbuild:
Runtime testing: conda install gazebo
...
C:\ProgramData\Miniconda3\Library\share\gazebo\setup.bat
gazebo --verbose
Gazebo multi-robot simulator, version 11.3.0
Copyright (C) 2012 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org
[Msg] Waiting for master.
Gazebo multi-robot simulator, version 11.3.0
Copyright (C) 2012 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org
[Msg] Waiting for master.seems like something is blocking the network connection or the network connection is miss-configured somehow. The GUI did not appear. Did not have time to debug this. |
|
Which shell are you using? Powershell and Git Bash are currently know to not be working (see conda-forge/gazebo-feedstock#42). Note that it should not be necessary to call Note that it seems that you installed Gazebo in the base environment, it is generally recommended to avoid to install heavy packages in the base environment, but rather to create a new environment and install the dependencies that you want to use there. |
plain cmd.exe.
Thanks for the tip. Seems to me like it should not change the behavior of the problem, is this correct? |
|
@j-rivero it would be interesting to know which version of gazebo got installed, too. |
|
PS: this is exciting! I am happy to help in any way I can! |
|
Thanks @wolfv ! From my previous comment:
|
Installed with into a virtual environment (Python 3.8 if that matters) Set Set the windows firewall:
Ran Expected BehaviorThe command should show some messages and then pop up some GUI windows (I guess? I am new to Gazebo.) Actual BehaviorRunning from an Anaconda prompt for the virtual environment, after running Same behavior with Antivirus disabled. Same behavior from regular Please let me know if this is useful or too n00b-y to be helpful. I don't have a clear entry point into this, just found it trying to find Gazebo binary builds for Windows and thought I'd give it a try. |
Thanks @danzimmerman for the useful feedback! I personally think that any feedback is useful, until gazebo runs easily on Windows. Two additional questions:
|
Sorry, I did not notice this message. In theory not, but if there is some bug in environment variables handling somewhere that affects the behavior and cause the crash. |
|
Output of Output of original-comment-npe-conda-list-output.txt
Understood. I've been setting up ROS all day so it's kind of a knee-jerk reaction.
Server: Client:
You mean in the NVIDIA control panel? Same. Firewall rules were actually added when I first ran gazebo, okayed them in GUI window. Are there dependencies to gazebo conda-forge installation that conda wouldn't handle? I might be missing something? Also happy to create a cleaner environment to try this. I also don't know exactly how I'm going to interact with Gazebo. I've set up ROS melodic on Windows according to http://wiki.ros.org/Installation/Windows, using customized repos from https://ms-iot.github.io/ROSOnWindows/ where necessary. Aaaand... apparently, those Windows instructions mean I already have a working installation of Gazebo 9.13.1 on my Windows machine. That gazebo installation seems to be built as a DLL and only can be accessed using I expect that interacting with Gazebo via ROS is probably the way to go on Windows, so maybe I personally don't actually need to get this conda installation working. However, I'm happy to answer more questions. |
|
Sorry forgot the original-comment-npe-env-vars.txt By the way, before I did this I did remove a Now I get the following with The first time I run the command in a fresh Anaconda prompt window: The second and subsequent times I run the command: From a cmd window navigating to the bin directory but not activating the environment
From a raw cmd, after activating the virtual env: I'll try this on my personal laptop which I haven't tinkered with nearly as much with system-level tools/env variables. This feels like a mess. |
|
Tried this on my personal laptop (
I've attached the output of Fresh Environment (Runs) vs. Existing Environment (Fails) - Anaconda Prompt
Attempting manual install of those four dependencies into a clone of the I've distilled the differences between gaz383-npe-gaz_package_diffs.txt and for the original difference between npe-gaz383-package-differences.txt Outstanding Possible IssuesAdding models to the empty world results in I tried the FilesEnvironment varsI'm not really seeing differences in the environment vars: gaz383-envs.txt (WORKS)
|
By inspecting manually the I am not sure if we could debug in some way why Something that I did not think about is that probably instead of saving the
Is this happening also with the Gazebo installed by ROSOnWindows? In that case, I suggest to open a new issue in this repo as it is probably a Gazebo upstream problem. If instead if only happens with the conda binaries, please open an issue in https://github.com/conda-forge/gazebo-feedstock, thanks! |
Yep, done below. I can't attach YAML directly, so I zipped all the referenced files: I'm back on the work laptop starting fresh. I can reproduce this issue with a simple starting I can then verify that the installed OGRE build is at fault. Updating it explicitly to build Minimal Reproduction
|
They both fail, but differently, and ROS on Windows Gazebo 9.13.1 has a simple fix. It was failing with Perhaps related to
The Conda binary Gazebo 11 still fails on adding models from models.gazebosim.org with And with fuel.ignitionrobotics.org models with: I'll open a |
|
Thanks a lot @danzimmerman ! I think we are indeed reaching the core of the issue. Given that the issue is related to how the environment is created from a yaml file, could you also report the version of conda you have in the base environment? |
The tests above were run with I updated the base environment
That one works. |
|
thanks a million for testing this @danzimmerman ! |
|
Hi @danzimmerman , I recently tried to spawn your |
|
Cool, will try it again soon. |
|
Conda-installing gazebo (and ROS Noetic) are working for me now. |
|
That's great to hear! |
Hello, thank you very much for your solution. Did you install ROS Noetic via Conda? And could you tell how the ROS can be connected with Gazebo? Sorry, if it is off-topic of this issue. |
This is possible via the RoboStack channel, see the following link for reference:
ROS can be connected with Gazebo via the In general, for this kind of question a Answers&Question website like https://answers.ros.org/questions/ or https://answers.gazebosim.org/questions/ . |
I had to run the terminal as administrator (probably because conda is installed for all users), otherwise no problems during the installation. When I start gazebo, I get 2 new processes. Admittedly, I haven't tested running any simulation or loading models yet. Is there a shared test scenario/world I should try? Edit: I seem to have the same model reading/loading issues as @danzimmerman . verbose stdout... which, to me, looks like the pointer to the model is NULL instead of actually pointing to the object. |
The gazebo command also for Windows was added recently in #2864, so there could be problems. However, indeed it works by spawning two separate gzserver and gzclient process. I am not sure instead about the |
|
I use conda command prompt, and I get stuck on "[Msg] Waiting for master." weirdly, it randomly works sometimes [everything works] but most of the time it just gets stuck in "[Msg] Waiting for master." and it's not even generating any network traffic, and it's really weird, what I'm wondering is, why does it work? I don't get it, the few times that it did work, what was different?! Can this be a multi threading bug somewhere? |
|
Can you send your OS, and the output of conda list? |
|
Or also conda info |
|
win64. conda list: |
|
Thanks for tracking the bug down! I wonder if this is a general gazebo-on-windows problem or specific to conda-forge? |
|
It seems windows specific. If we just document this behaviour somewhere, it would be fine, so people know to kill zombie gzclient/gzserver/gazebo process if they get stuck in "Waiting for master." and everything else is fine, and it doesn't happen that much, like, if you start gazebo, and prematurely kill it superfast before it's all up, or some unnatural thing like that this issue might happen. I tried investigating further but it gets even weirder => if you do this on purpose (it may take multiple time to get the behaviour) and then try to attach a debugger to see what is the state of that "zombie" process, it just exits right away [the new gazebo would be -unstuck- and start working] not letting you attach, if you try dumping it => you get a broken empty dump. |
|
Perhaps @ivanpauno can provide tips on how debug further failures of this kind.
This make sense. I think at this point given the amount of feedback on this issue, it could make sense if we move some of the knowledge contained in this issue (i.e. how to install it and a few known issues, such as the one that you mentioned) in a piece of docs in https://github.com/osrf/gazebo_tutorials , what do you think @j-rivero ? |
I think that you guys did a great work on debugging and clarifying the whole thing, thanks so much. I would be happy to review a PR against gazebo_tutorials. If you don't want to deal with the format of the docs, I can translate a markdown format if that helps. Feel free to assign the PR to me. I'm looking for a bit of time to test the conda installation again. |
On windows? In linux what I did was finding a simulation where I could reproduce the issue. I also added extra cpu stress to make the issue easier to reproduce. Doing something similar on Windows should be possible (e.g. https://docs.microsoft.com/en-us/visualstudio/debugger/attach-to-running-processes-with-the-visual-studio-debugger?view=vs-2019#:~:text=You%20can%20attach%20the%20Visual,the%20debugger%20to%20the%20process.), but I don't have experience in that. |
Don't worry, the step that you described apply to more and less any platform with a debugger, thanks! Furthermore, I actually suspect that most bug of this kind are rather multiplatform, but this is just my personal guess. |
Thanks, this is really helpful! I did track down what's going on in my case (on windows) and it was indeed this issue: #2950 and the suggested change seems to fix it. |
The change in #2950 was included in Gazebo Classic 11.5.0, that was released yesterday and for which conda-forge binaries are now available: conda-forge/gazebo-feedstock#67 . Hopefully then that problem was solved. |
|
I am using Windows 8. I just did |
Hi @PrasadNR, thanks for the report! Indeed I am not sure anyone ever tested this on Windows 8. Could you open an issue in https://github.com/conda-forge/gazebo-feedstock/issues/new, with all the information required by the issue template? In particular, the list of packages that you obtain with Other things that could be helpful for debug:
I wonder if this comment conda-forge/vc-feedstock#37 (comment) is related. I remember that when I read it I tought it was a purely teoretical problem, but that is not the case it seems. : ) |
The Conda project has available a package for Gazebo11 inside the conda-forge organization. The Goal of the ticket is to evaluate if this installation is stable enough to go into our documentation.
Help wanted:
We are interested in knowing if our users on Windows can install and use it without problems. If you want to help, please follow Conda instructions to install anaconda, miniconda or other variant of it, try to install Gazebo from conda-forge and try to run a basic simulation on it. Please comment in the issue with details about Windows version, conda installer, problems/not-problems found, graphic card drivers installed and other information you find useful. You are also welcome to comment and help with other people's problem.
Windows specific: check #2901 for the list of configurations, problems or issues on Windows.
The text was updated successfully, but these errors were encountered: