Cannot open python operation file in PythonAPI/examples about dreyevr HOT 30 CLOSED

start_recording

Every time I tried to make PythonAPI and make package, This error occurs, but it seems the build is succeed.

I got this error when trying to build carla. 1.) Ensure that "wheel" is installed. You can do "pip install wheel" if it's not installed. 2.) Check to ensure that the "wheel" installation path is added to PYTHONPATH in your environment variables. Check "wheel" installation path by running "pip show wheel".

from dreyevr.

Hmm, try cleaning everything and removing the old .egg from the original PythonAPI build. Then you should be able to rebuild PythonAPI without errors. Can you upload a build log?

from dreyevr.

Hi @sunchongren It looks like this execution path only occurs if the try block fails to execute. You should be able to see what the exception was by including

except Exception as e:
        print(e)

between the try and finally in DReyeVR_AI.py:139.

The exception should be informative as to why the block failed to run and led to the finally block.

from dreyevr.

Oh yeah the error message is:

RuntimeError: time-out of 10000ms while waiting for the simulator, make sure the simulator is ready and connected to 127.0.0.1:2000

from dreyevr.

This means that the client did connect to the simulator in time. Do you have the simulator running simultaneously?

from dreyevr.

However, the server side is already started if I understand it right by excuting

./CarlaUE4.exe

from dreyevr.

Right, you start the server by running the CarlaUE4.exe executable (and you run it in vr with -vr flag). As long as the server is running, I'm not sure why you are getting this client connection error. Can you give me some more information:

• What framerate is the simulator running at (if its too slow, maybe increase the timeout duration with client.set_timeout(x))?
• What python instance are you using for this?
• Do you have any other processes running on port 127.0.0.1:2000? this might be the case if you have lingering instances of CarlaUE4.exe running but frozen.
  • In this case, you can go into Task Manager -> Details and end the CarlaUE4.exe process

from dreyevr.

Hey Gustavo, for the questions above:

1. I tried to use a large number as timeout, but it was not working
2. I am using python 3.8 in conda env
3. The weird thing here is when I run ./CarlaUE4.exe, I cannot find the tcp port information from cmd prompt (netstat), I can only find the process of CarlaUE4-shipping.exe running on another unrelated port
   

from dreyevr.

Interesting, ok you should kill all other instances of CarlaUE4 and continue from there.

Have you tried rebooting your system then trying again?

from dreyevr.

Hi! I had this issue initially too; rebooting solved it.

from dreyevr.

Rebooting didnt solve the problem.
A interesting thing I noticed is that when I run python on wsl, none of python file works.
However, when I use cmd prompt, some python scripts worked (dynamic_weather, DReyeVR-AI), and some not (generate_veicle, manual_control)

from dreyevr.

So I think the possible reason is I used wsl?
But something I am confused about is, after make package for DReyeVR, is some python script disabled?

from dreyevr.

Right, sorry for any confusion, but yes you are expected to use windows python python.exe rather than linux python python (bash/WSL) for the CARLA interactions (assuming you are using Windows as your host for DReyeVR).

The main reason we use WSL is to clone the repo and install the files over the CARLA installation. Then you can do everything in cmd prompt.

There should not be python scripts disabled for make package? Can you be more specific on what's going on?

from dreyevr.

I am using python script in path carla\Build\UE4Carla\0.9.13-1-g8854804f4-dirty\WindowsNoEditor\PythonAPI\examples\.
I did some experiments, and here are python script not successfully running: vehicle_physics.py, vehicle_gallery.py, tutorial.py, schematic_mode.py, manual_control.py,

from dreyevr.

For generate_traffic.py:

from dreyevr.

Thanks for the insight! Most of those scripts you posted have not been extensively tested by us so we don't support them (mostly those that spawn their own ego-vehicle, such as vehicle_physics, gallery, and manual control)

However, the schematic_mode.py script should work. Can you provide more details with the failure for this script?

In total we have tested and verified these scripts work:

start_recording.py (starts recording a session)
start_replaying.py (starts replaying a session)
show_recorder_file_info.py (converts the binary recordings to a human readable format)
DReyeVR_AI.py (enables the traffic-manager for DReyeVR autopilot)
DReyeVR_logging.py (prints all the eye tracker data to screen, or logs to ros if using rospy)
schematic_mode.py (wrapper over no_rendering_mode to draw ego vehicle)
dynamic_weather.py (changes the weather)

from dreyevr.

Thank you so much Gustavo, then I think my problem solved.
For the failure of schematic_mode.py:

from dreyevr.

Ah okay, sounds like a duplicate of #12 and I believe the solution has to do with you needing to rebuild the PythonAPI.

To do this run make PythonAPI in the Carla folder (this will build the DReyeVR-compatible version of the PythonAPI)

from dreyevr.

Thanks!

from dreyevr.

@GustavoSilvera It is still not working. Trying to search more possible reasons

from dreyevr.

Every time I tried to make PythonAPI and make package,
This error occurs, but it seems the build is succeed.

from dreyevr.

What do you mean clean everything @GustavoSilvera

from dreyevr.

try make clean

from dreyevr.

Unfortunately schematic_mode.py is still not working. Will try more things tommorow

from dreyevr.

But the interesting thing is no_rendering_mode.py do work

from dreyevr.

And the other thing I don't understand is for the error: Assertion failed: px != 0, file C:\workspace\carla\Build\boost-1.72.0-install\include\boost/smart_ptr/shared_ptr.hpp, line 734. The address in C:\ is even not exist.

from dreyevr.

Interesting. Not sure why this is happening. Would be happy to look at logs. I've also never seen this path before, but maybe its part of some cache in an earlier build that wasn't cleaned?

from dreyevr.

You are absolutely correct. Thanks!
@GustavoSilvera The problem solved by reinstall wheel.

from dreyevr.

@sunchongren Do you have any more updates with this issue? We included some related help in our F.A.Q page.

from dreyevr.

Yes it is solved. Thanks.

from dreyevr.