u/AlexThunderRex

Trained a quad to race a 90 m figure-eight gate track with PPO in our sim (Unreal Engine 5 + JSBSim). 96 drones in parallel, 100M steps on a laptop. The policy commands body rates, sees simulated sensors through an estimator and never gets ground truth.

Median lap is 5.7 s. A time-optimal planner (TOGT) does 4.72 s on the same quad, so it's about 20% off.

The weak spot is the take-off: only about half of the ground starts finish a lap. Anyone solved that with a curriculum, or by giving ground starts more weight?

Built on: Swift (Nature 2023) for the reward and mid-air starts
https://www.nature.com/articles/s41586-023-06419-4
TOGT https://github.com/FSC-Lab/TOGT-Planner

The eXplora is a dual-motor 3D-printed tailsitter designed by Marco Robustini and his team, open hardware under GPL-3.0. I built a JSBSim model of it (geometry from the STEP files, masses from the slicer projects and BOM, aero from AVL, prop tables from QPROP) and added it to PteroSim, a UAV simulator on Unreal Engine.

The video is an ArduPlane mission: vertical take-off, transition to wing-borne flight, turns, back-transition and landing. The aircraft runs as a QuadPlane tailsitter from the team's own parameter file.

The footage is not from the simulator's camera sensors. I recorded the flight in the Unreal editor, rebuilt it as a Level Sequence and filmed it with CineCameras placed where a real crew would put them: tripods on the ground, a drone, a camera ship flying formation and a hard mount on the wing. Rendered with Movie Render Queue at 1080p60.

Links:

• eXplora Tailsitter VTOL: https://github.com/robustini/eXploraVTOL
• The eXplora in PteroSim (JSBSim model, meshes, ArduPlane params, GPL-3.0): https://github.com/PteroLabsAI/PteroSimAircrafts/tree/main/explora
• PteroSim: https://github.com/PteroLabsAI/PteroSim-UAV-Simulator

PteroSim v0.3.0 is out. The main change is a vehicle editor. Aircraft are now plain files, JSBSim XML plus a .glb mesh, built and tuned inside the simulator, so you can add your own airframe without rebuilding anything and without sending your model to us.

Also in this release: VTOL, tiltrotor and quadtailsitter airframes, autopilot chosen per vehicle so PX4 and ArduPilot aircraft sit side by side, runtime sensor editing, gimbal control over MAVLink, and custom vehicle spawning from the Python SDK.

Any aircraft flies on any tier now, free included, with only simulation time limited per session.

Walkthrough: https://youtu.be/kMb_4tNX7l8
Build: https://github.com/PteroLabsAI/PteroSim-UAV-Simulator/releases/tag/v0.3.0
Aircraft library: https://github.com/PteroLabsAI/PteroSimAircrafts

License upfront so nobody wastes time: proprietary, free for personal, academic and non-commercial use, paid for commercial.

Happy to hear what breaks, and what airframe you would try first.

Hey everyone, I want to share a video tutorial showing how to connect ArduPilot to PteroSim.
The whole process takes about 90 seconds.
I'd love to hear your feedback and questions :)

Hi everyone!

Has anyone thought about adding an FPV setup to the new RC Batmobile Tumbler (42239)?

Are there any FPV setups that could be carried over from other RC models?

Thank you!

Built it from a JSBSim quad reference, assuming it'd fly X-axis forward. It kept diving right after vertical takeoff. Turns out JSBSim always computes lift along the body X-axis, and a tailsitter sits nose-up, so the reference was 90° off and the "lift" pointed the wrong way.

Fix was rotating every component into the tailsitter orientation and recomputing the mass/inertia tensor and aero references. Best part: it forced me to fix some genuinely bad code in my BaseAircraft setup class along the way.

Also kept the motors faithful to the real Swan-K1 (2212 KV980, 9×6, modest thrust) instead of the beefier idealized Gazebo values. It was harder to tune, but the point was matching real flight, not a sim that flies because the motors a bit unrealistic hah.

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.

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)