Login

u/AlexThunderRex

r/ROS r/reinforcementlearning r/unrealengine r/surfing r/diydrones r/UnrealEngine5 r/robotics r/ardupilot
▲ 78 r/ardupilot+4 crossposts

Tunnel drone inspection SITL

How do you handle optical-flow dropout in GPS-denied tunnels?

Been poking at navigation for tight indoor/underground spaces (tunnels, under bridges) where GPS just drops and there's nothing to fall back on. The annoying part is optical flow basically dies in there: bare concrete, repeating geometry, almost nothing to lock onto. Ends up being mostly lidar plus an illuminated camera doing the work.

Testing it in sim first for obvious reasons (not keen on flying real hardware into a concrete wall to find the failure modes). Running it on UE5 with PX4/ArduPilot in the loop.

For those who've flown GPS-denied in feature-poor spaces: do you just lean harder on lidar, or is there a VIO setup that actually holds up when the visual texture is that poor? Curious what's worked.

u/AlexThunderRex — 12 days ago
▲ 7 r/diydrones+4 crossposts

Made a quick tutorial on getting a drone flying in our UE5 sim

After releasing the free version of PteroSim (UE5 sim with full 6-DOF flight dynamics and firmware in the loop for PX4/ArduPilot), I noticed two things in the questions people were sending.

First: a lot of newcomers who have never touched a simulator and have no idea where to start. So I recorded a short walkthrough on getting a drone up from scratch in about 90 seconds on PX4, not counting the flight controller setup.

Second, and this one made me laugh: some people were apparently searching for "Petro", typo'd their way into "Ptero", and then asked why we do not have Petro. So I made them a Petro. It is an offshore oil platform in the middle of the ocean, we use it for drone inspection scenarios.

youtube.com
u/AlexThunderRex — 27 days ago
▲ 3 r/unrealengine

Something wipes ShaderCompileWorker + half the Win64 engine tools out of my installed build during in-editor automation tests.

UE 5.7 from source (custom fork), made an installed build via RunUAT BuildGraph -target="Make Installed Build Win64". Engine is flat, registered, editor opens, shaders compile. Then I run automation tests in-editor and partway through the run Engine/Binaries/Win64 gets gutted: 32 exes down to 4, ~1200 DLLs down to ~460. ShaderCompileWorker, InterchangeWorker, UnrealLightmass, UnrealPak, zen, UBA, all gone with their .modules/.target. Editor then dies with "Unable to launch ShaderCompileWorker".

Tell-tale sign: the only 4 exes that survive are the ones that were running (UnrealEditor, CrashReportClientEditor, EpicWebHelper, LiveCodingConsole). Everything not holding a file lock gets deleted.

Ruled out:

  • Not external UBT. Runs -FromMsBuild, says up-to-date, deletes nothing (log below).
  • Not layout. Flat root vs BuildGraph's Windows\ subfolder: same wipe.
  • Not receipts. All 26 .target present before the run, including ShaderCompileWorker.target.
  • Not reproducible on an Epic Launcher installed build with the same project/tests.

Constant every time: Visual Studio is open (devenv + ServiceHub + MSBuild nodes), and Live Coding starts at boot despite bEnabled=False.

Live Coding starting even though it's disabled in DefaultEditorPerProjectUserSettings.ini:

[2026.06.02-03.29.12:544][0]LogLiveCoding: Display: Starting LiveCoding
[2026.06.02-03.29.12:544][0]LogLiveCoding: Display: LiveCodingConsole Arguments: UnrealEditor Win64 Development
[2026.06.02-03.29.13:603][0]LogLiveCoding: Display: Successfully initialized, removing startup thread

The UBT that runs at the same time, doing nothing:

Command line: ...\UnrealBuildTool.dll PteroSimEditor Win64 Development -Project=...\PteroSim.uproject -WaitMutex -FromMsBuild -architecture=x64
Generated code is up to date.
Target is up to date
Result: Succeeded

Exact moment of the wipe (my file watcher on ShaderCompileWorker.exe + live process list):

SCW-DELETED 11:33:06 | test=[PteroSim.License.Flow.Attack.TamperedLic]
  procs=[MSBuild, ServiceHub.Host.dotnet.x64, UnrealEditor, UnrealTraceServer]
  ubt-tail=[Target is up to date / Result: Succeeded]

So: what mass-deletes engine Win64 binaries from an installed build mid-test? Live Coding's in-process delete-before-relink deciding the engine is stale? A VS background/design-time MSBuild? And what's the right way to actually trace the delete (procmon stack?) and to genuinely disable Live Coding in an installed build, since the ini flag isn't doing it?

I followed this instruction:
https://dev.epicgames.com/documentation/unreal-engine/create-an-installed-build-of-unreal-engine

[logs gist](https://gist.github.com/AlexanderRex/f1f346d7d417baa80de6decc1cf8cd1d)

reddit.com
u/AlexThunderRex — 1 month ago