Make launch failure with 0.9.13 about dreyevr HOT 18 CLOSED

Hmm. I haven't seen this error before. Did you run make LibCarla before running make launch?

Try make clean after installing DReyeVR, then make LibCarla && make PythonAPI && make launch again

generally, lowercase namespaces and code in the carla simulator (such as carla::road::element::RoadInfoSignal, the type of the auto'd SignalReference) are part of the LibCarla program which is not built when building UE4. So my first guess is that there is some problem with LibCarla here.

from dreyevr.

Well what do you know! Once I put in the exception handling code you mentioned in EgoVehicle.cpp the linker error is gone and make launch works successfully. Does it mean throw_exception() is silently called somewhere during build? Or was it just the missing definition that was the issue?

It appears for the time being I should unfortunately proceed without DReyeVR's custom sensors until someone in Carla can figure out what's causing this sort of problem. Since this pattern seems very consistent with the aforementioned github issue I now have reason to suspect it's a problem with how custom sensors are handled in Carla.

It's a bummer that replicating this error itself is also an enigma, but to list what was common in the two problematic devices I worked with:

Hardware

• NVidia GPU (different specific models, 10xx and 30xx)
• AMD 5xxx CPU (different specific models. I'm aware there are some software differences between Intel and AMD CPUs, such as BLAS related libraries, but I'm not sure that's relevant here.)

Software

• x64 Windows 10
• system locale was at least temporarily changed to non latin alphabet based language at some point
• Other software requirements for building carla from source
• python 3.x x64 (conda/native agnostic, tried with 3.8 and 3.9)
• Carla related required environment variables (%CARLA_ROOT%, %UE4_ROOT%, cmake, GNU make etc.)
• source file encodings(both carla and DReyeVR) not altered from original

For now being able to use carla as a first-person driving emulator that supports HMD with the added benefits of audio is enough for me. I'll have to see if the slew of modifications I made causes any crashes while running sessions without custom sensors. Thank you for your help!

from dreyevr.

Interesting! Well, we're glad the CARLA+DReyeVR setup you have works for you, but we are eager to investigate this issue if it arises again in a reproducible manner.

Thinking about the modifications you have made, you might run into problems when using the PythonAPI with our custom scripts. Specifically, functions that call find_ego_sensor and expect a Carla sensor might raise problems.

from dreyevr.

That is great news, I have just created a fresh carla install with the modifications mentioned in the PR and found that DReyeVR now works fresh out of the box. Thank you for the update! I am now marking the issue closed.

from dreyevr.

Huh. looking at the file where the error is happening (Unreal/CarlaUE4/Plugins/Carla/Source/Carla/Traffic/YieldSignComponent.cpp) it appears that the file itself was never modified during the DReyeVR installation.

I have never run make LibCarla on its own before, I assumed the command was run somewhere within the main commands.
Anyways, I ran the commands you suggested (make clean -> make LibCarla -> make PythonAPI -> make launch) again, and it seems the error is persisting.

make LibCarla put out too much lines that the log got cut off from my console, but it ran without issues.

Here's the make PythonAPI result:
dreyelaunch_log_make_pythonapi.txt

Here's the latest make launch result:
dreyelaunch_log_2_post_makeclean_and_remake.txt

from dreyevr.

Interesting. You are correct that LibCarla gets built by running PythonAPI but I though perhaps it was deleted somehow so explicitly running it again might fix it, oh well. Anyways, I'm not sure why this YieldSignComponent is causing so much trouble since this is never supposed to be modified in any way by us.

Would you mind including the console text from a git status (to see what files were modified) and a find . -type f -name "*.[ch]pp" command (to see all the source files in the carla directory). This should help me figure out if a stray file has been modified which shouldn't've been.

from dreyevr.

Here is the git status output:
dreyelaunch_git_status.txt

and here is the output from the bash find command (I did not remove the PythonAPI dependency source files from my folder so the list is a bit long)
sourcefile_list.txt

I'm trying to think of any irregularities during my install and there is one, although it was an issue with building osm2odr/xerces/etc. while making PythonAPI. But anyways, during the vanilla build of CARLA I ran into this issue & workaround:
carla-simulator/carla#4525 (comment)

I made fresh builds of CARLA multiple times and every time I did so I ran into it, in different devices with similar setups (x64 Windows, native python installation etc.). Not exactly sure if it was 0.9.13 specific but I think the issue was around in some of the previous versions too.

from dreyevr.

Okay, yeah nothing specifically looks out of the ordinary here. One thing I think could be a problem is that I've never used Python 3.9 for my carla builds, I've only ever used 3.7/8. Can you try following the conda guides in the docs.

Also, what do you mean by you "first removing the vanilla one through pip3"? Are you installing carla through pip? You shouldn't need to use pip at all if I recall correctly.

from dreyevr.

Apologies for the delayed reply, my workstation's PSU died for no apparent reason and I had to get replacements.

I've only ever used 3.7/8. Can you try following the conda guides in the docs.

I wish I had that link the last time I tried building Carla with Anaconda. I couldn't figure out where to modify so that it would run python instead of py, and I tried fiddling with registry to make py target my conda python to no avail. The link in your docs seems to get around that issue. I've remade PythonAPI with a conda env using Python 3.8. There still was another issue where building xerces-c failed during the process (I had to use a workaround where I installed xerces-c in the conda environment first, and then copied the built files into Carla's build folder: carla-simulator/carla#3320 (comment)). After that I ran into the same aforementioned issue and workaround from carla-simulator/carla#4525 (comment) . It looks like xerces-c really hates my Windows setup.

After all this I verified that make launch is working before installing DReyeVR. Once I installed DReyeVR and tried again the same issue surfaced:
dreyelaunch_log_make_launch_py38_conda.txt

So I'd say it's not the python version nor conda/native python that's causing the issue.

edit
I'm thinking of other things that might be a problem.. When you build PythonAPI in your Windows setup, do you ever get any Unicode related warnings? I specifically get a ton warnings regarding unicode and CP949 whenever I build carla:

dependencies/include\carla/road/element/RoadInfoMarkRecord.h(1): warning C4819: The file contains a character that cannot be represented in the current code page (949). Save the file in Unicode format to prevent data loss

I believe cp949 is syslocale code for Korean (which happens to be my current rig's system locale on windows). Seeing how a good number of error messages popping up in YieldSignComponent.cpp are syntax errors complaining about missing semicolons etc. that don't make sense, I'm wondering if there is some conversion of file encodings from whatever format the source files are in into cp949 going on, in which a whitespace or non-text info goes missing either when building carla or installing DReyeVR. All cp949 related messages were warnings and not errors, and since they didn't interfere with using carla on its own I've ignored them up till now.

Also, what do you mean by you "first removing the vanilla one through pip3"? Are you installing carla through pip? You shouldn't need to use pip at all if I recall correctly.

By pip3 I meant installing the built pythonAPI .whl in the python environment for the scripting part. I think it's a rather new option to use .whl since 0.9.12? whereas the .egg file doesn't need any installing. I figured that DReyeVR might make changes to the PythonAPI and I'd need to reapply the python wheel as well.

from dreyevr.

Hmm interesting, yes I agree it is unlikely that the python version/type is the problem here. Also no, I have never seen those letter encoding problems before but that definitely might be the cause of these problems. According to this MS doc on C4819, it might be worthwhile to unify all the source files in Carla to be either all UTF-8 or all cp949.

Maybe try something like this:
reset carla to HEAD

# in carla/
git reset --hard HEAD  # resets changed files
git clean -fdx                # removes new files

convert all DReyeVR files to CP949

cd /path/to/DReyeVR
git pull origin main # get the most up-to-date version
find . -exec iconv --verbose -f utf-8 -t CP949 -o {} {} \;

install back to carla

make install CARLA=/path/to/carla

Then try make launch'ing again. I found that there were three files that might have problems with non standard encodings (and these will be patched in the upcoming update):

DReyeVR/EgoInputs.cpp:281-282 (these are just comments, try deleting them)
Docs/Install.md (should not be installed to Carla)
Docs/Signs.md (should not be installed to Carla)

I also found that xercesC hates my Windows machine too, I had to follow those same workarounds to get Carla to work as well, so that seems to be locale-agnostic.

from dreyevr.

For reasons unrelated to DReyeVR but quite annoyingly git clean broke my carla. I get bunch of LNK1120 and LNK2001 errors while building LibCarla. Just another carla thing I guess, but the workarounds with just running make PythonAPI didn't work anymore so I had to re clone the carla repo instead.

Also oddly after running the iconv command the encodings did not change at all:
/mnt/c/CarlaProject/DRVR_913/DReyeVR$ file * --mime-encoding DReyeVRUtils.h: us-ascii EgoInputs.cpp: iso-8859-1 EgoSensor.cpp: us-ascii EgoSensor.h: us-ascii EgoVehicle.cpp: us-ascii EgoVehicle.h: us-ascii FlatHUD.cpp: us-ascii FlatHUD.h: us-ascii LevelScript.cpp: us-ascii LevelScript.h: us-ascii

I think this is because the files never really contained any letters that might cause potential encoding conflicts:

In any case there were also CP949 related warnings while building libcarla and dependencies (specifically boost). I think it's either the windows console/make/cmake that's forcefully reading source files in CP949. So instead of re-encoding the source files of all these, I temporarily changed my OS' locale into en-US and rebuilt PythonAPI.

After that I no longer get any encoding related warnings, but once I install DReyeVR I still get the same error down the line:
dreyelaunch_log_post_locale_make_launch.txt

To make sure I also made a fresh install of CARLA under the new locale and did everything again, and I'm still getting the same error. I no longer think it's a locale issue.

There seems to be a recurring message in there about a certain circular dependency in a couple of header files though. Would that be an issue?

Running UnrealHeaderTool "C:\CarlaProject\c913d_condapy38\Unreal\CarlaUE4\CarlaUE4.uproject" "C:\CarlaProject\c913d_condapy38\Unreal\CarlaUE4\Intermediate\Build\Win64\CarlaUE4Editor\Development\CarlaUE4Editor.uhtmanifest" -LogCmds="loginit warning, logexit warning, logdatabase error" -Unattended -WarningsAsErrors -abslog="C:\binaries\carUE426\Engine\Programs\UnrealBuildTool\Log_UHT.txt" LogCompile: Error: Circular dependency detected for filename C:\CarlaProject\c913d_condapy38\Unreal\CarlaUE4\Source\CarlaUE4\DReyeVR\EgoVehicle.h! LogCompile: Error: Circular dependency detected for filename C:\CarlaProject\c913d_condapy38\Unreal\CarlaUE4\Source\CarlaUE4\DReyeVR\LevelScript.h!

from dreyevr.

Ah, apologies for the git clean mess, it probably also cleaned up any and all files (not ignored by git) that were build files. Ok yeah it looks like locale might not be the issue, and those recurring circular dependencies are also not an issue (the UnrealBuildTool handles it).

Here are the only things we are unsure about:

• Is your UnrealEngine version the same? CarlaUnreal/UnrealEngine (main)
• Our MSVC build is slightly newer (Visual Studio 2019 14.29.30139 & Windows 10.0.19041.0 SDK) than yours (Visual Studio 2019 14.28.29914 & Windows 10.0.18362.0 SDK). We doubt this is the cause but it is a difference.
• Are you sure you're on the latest 0.9.13 Carla branch (commit a1b37f7f1cf34b0f6f77973c469926ea368d1507)
• Is your %CARLA_ROOT% variable correctly set to your \PATH\TO\CARLA
• Does running git diff in the carla directory highlight any strange characters like ^M?

Besides those minor things, we're out of ideas in terms of what could be going wrong, maybe instead of using a vanilla Carla 0.9.13 build and installing DReyeVR to that, we'd like to have you try using our fork of Carla 0.9.13 with the DReyeVR source code already installed. However, after running Update.bat/sh in it you'll still need to install DReyeVR over it to copy over some blueprints and other custom content.

So, try:
(in bash)

git clone https://github.com/HARPLab/carla -b DReyeVR-0.9.13 --depth 1

As a sanity check, once you install DReyeVR to this new fork, you should see very few files actually changed (as of writing, only EgoVehicle.cpp is different bc our carla fork is slightly ahead of the public DReyeVR release, but its minor refactoring).

(in batch, x64 Native Tools Command Prompt)

cd carla
Update.bat

(back in bash, need to have updated content in order to install DReyeVR)

cd DReyeVR/
make install CARLA=../carla # install over the fork

(finally, last steps are in batch)

cd carla
make PythonAPI && make launch

from dreyevr.

I have retried with the forked version of Carla in your repo and found that the same error occurs at make launch post DReyeVR install.

To go over the checklist:

Is your UnrealEngine version the same? CarlaUnreal/UnrealEngine (main)

Yes, it is the forked Unreal 4.26 used in Carla version 0.9.13. Before running make I checked with the unreal version picker that carla's uneral project file targets the forked Unreal 4.26 correctly.

Our MSVC build is slightly newer (Visual Studio 2019 14.29.30139 & Windows 10.0.19041.0 SDK) than yours (Visual Studio 2019 14.28.29914 & Windows 10.0.18362.0 SDK). We doubt this is the cause but it is a difference.

My device has both 10.0.18362.0 and 10.0.19041.0 installed but it seems to default to the older one. In a different device that only has 19041 I've tried installing carla (vanilla 0.9.13, not the DReyeVR fork) & DReyeVR and got the same result. Said different device is a rather recently set up windows machine with anaconda python 3.9.

Are you sure you're on the latest 0.9.13 Carla branch (commit a1b37f7f1cf34b0f6f77973c469926ea368d1507)

Positive, considering that there would be warning messages otherwise (I found that while trying on a master branch clone of carla).

Is your %CARLA_ROOT% variable correctly set to your \PATH\TO\CARLA

Yes. I checked the Carla root environment variable as well.

Does running git diff in the carla directory highlight any strange characters like ^M?

None that I can see. I did not find any broken escape characters etc.

At this point I am out of ideas as well. I suspect it's something in my environment that messes with carla during an install, but I have no clue what.

Edit

Maybe I was focusing on the wrong part of the error message. You may have noticed but the error always terminates with

make: *** [CarlaUE4Editor] Error 6

There seem to be several github issues on the carla repo, possibly something with the %UE4_ROOT% environment variable. Odd because that variable is set correctly on my device and runs with no issues on the vanilla carla version. I am seeing that one person commented deleting the non-carla Unreal with the same version solved said error, so I think I'll try that now. (I do have both a Carla fork UE426 and the official UE426, but their pathnames are distinct enough that I wouldn't confuse them accidentally).

This did not solve the issue.

I've also checked for any line ending (CRLF vs LF) inconsistencies between my carla and clone of DReyeVR, which wasn't the case.

I wonder if deregistering the DReyeVR specific sensors might do anything?

from dreyevr.

(Apologies for the late response)

Interesting... I have never seen this error before (With the BoundingBoxCalculator) but it seems to be similar (and similarly unsolved) to the problem you're having.

It might be worthwhile to ignore the DReyeVRSensor for now (Since this appears to be a bug on CARLA's custom sensor implementations) by removing the Carla/Sensor/DReyeVR* files and getting it to build (will unfortunately require some patchwork).

Now this might be a big ask, but if you think it might be a problem with your particular machine, have you tried building CARLA+DReyeVR using a fresh OS install? I'm not sure if some environment variables might be causing a problem.

from dreyevr.

It might be worthwhile to ignore the DReyeVRSensor for now (Since this appears to be a bug on CARLA's custom sensor implementations) by removing the Carla/Sensor/DReyeVR* files and getting it to build (will unfortunately require some patchwork).

Approaching this in steps. First, I removed the DReyeVR sensor imports from /libcarla/source/sensor/SensorRegistry.h without removing the actual sensor definition files. -> didn't work

Next, I removed sensor definition files from /libcarla/source/sensor/(data, s11n), namely DReyeVRSerializer.* and DReyeVREvent.h -> didn't work

Next, I removed DReyeVRData.* DReyeVRSensor.* from /unreal/carlaue4/plugins/carla/source/carla/sensor -> [CarlaUE4Editor] error 6, but different error (no more YieldSignComponent syntax errors) complaining about missing references called in EgoSensor (which was expected)

From here, since the nonsensical YieldSignComponent error was no longer occuring I moved on to making make launch work, by repeatedly running it and manually resolving reference errors from deleted sensor files.

Next, I removed EgoSensor.* while modifying EogVehicle.cpp and EgoVehicle.h to remove references to EgoSensor.* related stuff (in order, you can see that at some point I reverted the deletion of DreyeVRData.h):

• removing Egonsensor.h and DreyeVRData.h include in Egovehicle.h
• commenting out EgoSensor class def, method calls etc in Egovehicle.cpp
• block commenting out AEgoVehicle::ReplayTick()
• block comment on UpdateSensor()
• comment out EgoSensor Code in BeginDestroy()
• Comment Egosensor conditional block in UpdateDash()
• removed EgoSensor section in DReyeVRConfig.ini
• removed include DreyeVRdata.h from DReyeVRRecorder.h and references in cpp
• reinstated DReyeVRdata.h after seeing that it just defines a bunch of datatypes (and dreyevRrecorder complained)
• Removed reference to dreyevrsensor in carlarecorder.cpp and commented related code
• removed reference to dreyevrsensor in carlareplayerhelper.cpp and commented out DreyeVRSensor method calls, commented out contents of ProcessReplayerDReyeVRData()
• removed reference to dreevrsensor in levelscript.cpp
  And then make launch ->
  At this point I get a completely different error:

Using Visual Studio 2019 14.29.30140 toolchain (C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133) and Windows 10.0.19041.0 SDK (C:\Program Files (x86)\Windows Kits\10).
[Upgrade]
[Upgrade] Using backward-compatible build settings. The latest version of UE4 sets the following values by default, which may require code changes:
[Upgrade]     bLegacyPublicIncludePaths = false                 => Omits subfolders from public include paths to reduce compiler command line length. (Previously: true).
[Upgrade]     ShadowVariableWarningLevel = WarningLevel.Error   => Treats shadowed variable warnings as errors. (Previously: WarningLevel.Warning).
[Upgrade]     PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs   => Set in build.cs files to enables IWYU-style PCH model. See https://docs.unrealengine.com/en-US/Programming/BuildTools/UnrealBuildTool/IWYU/index.html. (Previously: PCHUsageMode.UseSharedPCHs).
[Upgrade] Suppress this message by setting 'DefaultBuildSettings = BuildSettingsVersion.V2;' in CarlaUE4Editor.Target.cs, and explicitly overriding settings that differ from the new defaults.
[Upgrade]
Building 4 actions with 16 processes...
  [1/4] LevelScript.cpp
  C:\CarlaProject\c913b_conda39\Unreal\CarlaUE4\Plugins\Carla\Source\Carla/Vehicle/CarlaWheeledVehicle.h(63): warning C4996: 'AWheeledVehicle': PhysX is deprecated. Use the AWheeledVehiclePawn from the ChaosVehiclePhysics Plugin. Please update your code to the new API before upgrading to the next release, otherwise your project will no longer compile.
  C:\CarlaProject\c913b_conda39\Unreal\CarlaUE4\Plugins\Carla\Source\Carla/Vehicle/CarlaWheeledVehicle.h(163): warning C4996: 'UWheeledVehicleMovementComponent4W': PhysX is deprecated. Use the UChaosWheeledVehicleMovementComponent from the ChaosVehiclePhysics Plugin. Please update your code to the new API before upgrading to the next release, otherwise your project will no longer compile.
  C:\CarlaProject\c913b_conda39\Unreal\CarlaUE4\Plugins\Carla\Source\Carla/Game/CarlaHUD.h(53): warning C4996: 'UWheeledVehicleMovementComponent': PhysX is deprecated. Use the UChaosWheeledVehicleMovementComponent fron the ChaosVehiclePhysics Plugin. Please update your code to the new API before upgrading to the next release, otherwise your project will no longer compile.
  C:\CarlaProject\c913b_conda39\Unreal\CarlaUE4\Plugins\Carla\Source\Carla/Game/CarlaHUD.h(54): warning C4996: 'UWheeledVehicleMovementComponent': PhysX is deprecated. Use the UChaosWheeledVehicleMovementComponent fron the ChaosVehiclePhysics Plugin. Please update your code to the new API before upgrading to the next release, otherwise your project will no longer compile.
  [2/4] UE4Editor-CarlaUE4.lib
     Creating library C:\CarlaProject\c913b_conda39\Unreal\CarlaUE4\Intermediate\Build\Win64\UE4Editor\Development\CarlaUE4\UE4Editor-CarlaUE4.lib and object C:\CarlaProject\c913b_conda39\Unreal\CarlaUE4\Intermediate\Build\Win64\UE4Editor\Development\CarlaUE4\UE4Editor-CarlaUE4.exp
  [3/4] UE4Editor-CarlaUE4.dll
     Creating library C:\CarlaProject\c913b_conda39\Unreal\CarlaUE4\Intermediate\Build\Win64\UE4Editor\Development\CarlaUE4\UE4Editor-CarlaUE4.suppressed.lib and object C:\CarlaProject\c913b_conda39\Unreal\CarlaUE4\Intermediate\Build\Win64\UE4Editor\Development\CarlaUE4\UE4Editor-CarlaUE4.suppressed.exp
  carla_server.lib(Exception.obj) : error LNK2019: unresolved external symbol "void __cdecl carla::throw_exception(class std::exception const &)" (?throw_exception@carla@@YAXAEBVexception@std@@@Z) referenced in function "void __cdecl clmdep_asio::detail::throw_exception<class std::bad_cast>(class std::bad_cast const &)" (??$throw_exception@Vbad_cast@std@@@detail@clmdep_asio@@YAXAEBVbad_cast@std@@@Z)
  C:\CarlaProject\c913b_conda39\Unreal\CarlaUE4\Binaries\Win64\UE4Editor-CarlaUE4.dll : fatal error LNK1120: 1 unresolved externals
make: *** [CarlaUE4Editor] Error 6

I feel like we've reached near the bottom of the issue. Would this error be related to sensor references in PythonAPI? Make pythonAPI works fine however, it only happens at make launch. A cursory search shows that the cryptic error message has to do with type casting stuff in boost. I know very little about cmake and boost so I don't really know how to proceed from here. But it appears the issue might stem from core carla lib and then somehow triggers when you run DReyeVR related code?

I could keep doing ablation to the code files to get further down the rabbit hole, but I'd like to see what you think first.

Now this might be a big ask, but if you think it might be a problem with your particular machine, have you tried building CARLA+DReyeVR using a fresh OS install? I'm not sure if some environment variables might be causing a problem.

This all was in pretty good timing because I just recently had to install a new PC that our lab will use for VR experiments. Very similar setup with my current station (x64 windows, anaconda, VSstudio and unreal). I tried installing CARLA+DReyeVR on this rig.

Disregarding the sensor removal steps I did above, again make launch worked with vanilla Carla but not post DReyeVR installation, same nonsensical error on YieldSignComponent.cpp.

The added user environment variable in %PATH% were anaconda, cmake, and make.
Otherwise the manually added system environment variable were %CARLA_ROOT% and %UE4_ROOT%.

Using the latest VStudio 19, Windows SDK 10.0.19041, .NET 4.x (it has both 4.6.2 and 4.8 but seems like it somehow keeps defaulting to 4.8 building Unreal, but no problems with running it so I'm letting it be. In my original workstation it builds with 4.6.2) and anaconda python 3.9. OS was initially installed en-US locale, changed to cp949 momentarily and then back to en-US for unrelated reasons (force of habit) before carla installation.

Aside from this I'm not really sure what you can do to replicate my errors.

Another question, would the HMDs need to be connected and powered on before make launch? And would an unsupported older Oculus HMD (Dk2) might be a problem? I've tried with the HMD both powered on and off and it still didn't work, but since it's an older HMD I'm not sure.

from dreyevr.

Hi, wow you are certainly going through a journey here. Ok I will do my best to help where I can:

First off, regarding the exception linker error you were getting, this is because you probably also got rid of this little bit in the EgoSensor.cpp:

#ifndef NO_DREYEVR_EXCEPTIONS
#include <exception>
#include <typeinfo>

namespace carla
{
void throw_exception(const std::exception &e)
{
    // It should never reach this part.
    std::terminate();
}
} // namespace carla
#endif

If you include this in the EgoVehicle.cpp then I believe this linker error should no longer be an issue.

Regarding your completely fresh PC, yeah I really don't know what's going on here.

For your last question, make launch does not need the HMD's to be connected because UE4 handles all the VR components. If you want to try the VR preview (in editor) or use the -vr flag then you'll need SteamVR + your HMD to be running.

While I haven't tested with an older HMD like the Oculus DK2, I would think that SteamVR enabled headsets should work, so as long as SteamVR works with your headset then you should be able to see a message such as:

# is detected
LogTemp: HMD detected: SteamVR, version 4.26.2-0+++UE4+Release-4.26, Driver: lighthouse, Serial: XYZ, HMD Device: HTC VIVE_Pro MV, Driver version: TrackedProp_UnknownProperty

# not detected
LogTemp: Warning: No head mounted device detected!

from dreyevr.

Thank you. I'll have to look into the python code for a workaround as well then.

In the meantime I found a fresh github issue in carla that has the exact same messages popping up, but only with an unmodified installation of carla which is very peculiar. I am tagging this post there to see if the carla team responds.

from dreyevr.

Hey again! So just our luck, we managed to find a computer where this build problem was happening. I wrote up a quick solution and submitted a patch to CARLA in the form of PR #5217. Hopefully this can allow you to install DReyeVR correctly and without hassle :)

from dreyevr.