OpenHUTB/hutb: A CARLA-Derived Simulator That Adds Drones, VR Cockpits and Underwater Robots

What problem the simulator is actually solving

The README frames the project as a film-grade physics simulator for humans and vehicles, built to speed up algorithm development, training and validation for both people and robots. That phrasing matters. The target is not a game engine demo but a research loop: you write a control or perception algorithm, run it against synthetic humans and machines, and get numbers back. The stated scope covers embodied humans, ground vehicles, airspace vehicles and water vehicles, each with its own documentation page. Alongside the code, the project ships what it calls freely usable open digital assets: town layouts, buildings, vehicles, pedestrians and props. For a lab, that asset library is often the deciding factor, because building a believable town from scratch in Unreal is a separate project on its own. The people this is for are robotics and autonomous-driving researchers who need more than one agent class in the same world. A team studying pedestrian-vehicle interaction and also flying a drone over the same street has a reason to care. A team that only needs a fixed-wing autopilot test does not.

The CARLA lineage is visible in the directory layout

The Python API lives at PythonAPI/carla/dist, the examples live under PythonAPI/examples, and the utility script is PythonAPI/util/config.py. Those paths are the CARLA convention, and the README's example scripts (generate_traffic.py, manual_control.py) follow the same naming. The ecosystem section lists bridges and tools that are CARLA projects by URL: scenario_runner, ros-bridge, driving-benchmarks, carla-autoware, carla-map-editor, plus a community Apollo bridge. The practical reading is that hutb is a fork or derivative that keeps the client-server shape and extends the world with air and water agents. The v2.3.0 release notes state that from that version the simulator supports Carla mode and AirSim mode simultaneously, which is the clearest signal of how the extension was done: rather than replacing the vehicle API, an air mode was added beside it. If you have existing CARLA client code, the migration cost is likely small, but the README does not promise API compatibility, so treat that as an expectation to test rather than a guarantee.

Getting a running instance: downloader, wheel, then config.py

The README gives two routes. The fast route is to run the simulator downloader, a Windows executable hosted on Gitee, then install the Python wheel from the generated hutb/PythonAPI/carla/dist/ directory with pip install hutb-*.whl. The README states the wheel supports Python 3.7 through 3.14, which is an unusually wide band and worth confirming against your interpreter before you build anything on top of it. From there, three example commands are given. To populate a scene with traffic: python PythonAPI/examples/generate_traffic.py. To drive a pedestrian by hand with a filter: python PythonAPI/examples/manual_control.py --filter walker.pedestrian.*. To switch the running map into VR cockpit mode: python config.py --map Town10HD?GAME=VR, after which the README says a Logitech wheel or the W, A, S, D keys work, with Z for reverse. The air mode uses the same script with a different query string: python config.py --map Town10HD?GAME=AIR, followed by python PythonClient/multirotor/hello_drone.py, with the README noting that pressing Enter after takeoff cycles through states. The GAME= parameter inside the map string is the mechanism that selects which simulator mode the level loads in, and it is the one piece of configuration a new user must get right.

Building from source, and the hardware floor

Source builds go through setup.bat, with setup.bat -l to launch the editor and setup.bat -p to package. The README points to separate Windows and Linux build guides in the documentation, and notes that the hutb branch carries the newest version plus the latest fixes and features. That last point is a warning as much as a convenience: if you build from hutb, you are on the development branch by default. The stated hardware requirements are an Intel i7 or i9 from the 9th to 11th generation, or an AMD Ryzen 7 or 9, at least 16 GB of RAM, an NVIDIA RTX 2070 or better, and Windows 10+, Ubuntu 18.04+ or macOS 12+. Two things stand out. First, no storage figure is given, and Unreal projects with a town-scale asset library are large, so budget for that yourself. Second, Ubuntu 18.04 is the floor, which is an old LTS, and the README does not say which newer distributions are known to work. For artists, the README offers an escape hatch: download hutb_editor.zip from a Baidu Pan link and run launch_hutb_editor.bat to get the editor with plugins, no compilation needed.

Where the project is thin, and where it is the wrong tool

The documentation is Chinese-first. The README links an English README_EN.md and an English-language page, but the body text, release notes and the bulk of the linked doc site are in Chinese, and the release titles are Chinese strings such as the v2.10.0 note about embodied humans, drones and unmanned vehicles in one simulation. For a team without Chinese readers, that is a real onboarding cost, not a cosmetic one, because the details you need when something fails are in the doc site. The release history is also irregular. The tags run v2.2, v2.3, then v2.10.0, with roughly a year between v2.2 and v2.3 and then a jump in numbering. Nothing in the supplied material explains the versioning scheme, so you cannot infer a cadence from it. The distribution channel is a further constraint: the primary download is a Windows .exe hosted on Gitee, and the editor build is on Baidu Pan, both of which are awkward or blocked for some users outside China. This is the wrong tool if you need a headless, Linux-first CI pipeline for regression testing, or if your work is single-domain and a lighter simulator would do. It is also the wrong tool if you need a vendor to answer a support ticket.

How it relates to CARLA and to AirSim

The honest comparison is with CARLA, because hutb reuses its client API shape, its example scripts and much of its surrounding toolchain. The difference in approach is scope: CARLA is an autonomous-driving simulator, and hutb's stated aim is to put embodied humans, ground vehicles, airspace vehicles and water vehicles into one environment. The README explicitly credits separate plugins for the extensions, with a MuJoCo plugin repository for underwater work and an air plugin repository for drones, and the v2.3.0 note about Carla mode and AirSim mode coexisting tells you the air side borrows from AirSim conventions rather than inventing a new drone API. So the choice is not hutb versus CARLA on quality, it is whether you need the extra agent domains. If you only need cars, CARLA's documentation is larger and its English material is deeper. If you need a drone flying over the same street where your pedestrians are walking, hutb is doing something CARLA alone does not, and the cost is a smaller, Chinese-language documentation surface and a less predictable release trail.

Licence and the cost of staying current

The repository is MIT-licensed, and the README's badge row shows a license badge reading MIT. MIT is permissive, so redistribution and commercial use are broadly allowed, but the repository also ships or links digital assets whose own terms may differ from the code licence. The README describes the assets as freely usable, yet the supplied material does not include a separate asset licence file, and a badge is not a licence text. Check the actual LICENSE file and any asset terms in the repository before shipping anything derived from the towns, vehicles or pedestrians. On maintenance cost, the practical expense is Unreal Engine itself: engine upgrades, plugin compatibility, and the size of a town-scale project on disk. The README's own split between the hutb branch and the documentation suggests you will be tracking a moving target if you build from source, and the downloader route trades that for depending on a prebuilt binary whose contents you did not compile. Neither route is free of upkeep, and the material does not describe a long-term support branch.

Editorial conclusion

Adopt OpenHUTB/hutb if your work needs pedestrians, ground vehicles, drones and underwater robots in one Unreal scene and your team already knows the CARLA Python API, because the import path PythonAPI/carla/dist and the config.py map switching carry over. Do not adopt it if you need a stable English-first API surface, a documented release cadence, or a support contract, since the README is Chinese-first, the release tags jump from v2.10.0 back to v2.3, and the downloader is a Windows .exe. Verify three things before writing code: that the wheel in PythonAPI/carla/dist installs on your Python version (the README claims 3.7 through 3.14), that your GPU meets the stated RTX 2070 floor, and that the map name you pass to config.py --map, such as Town10HD?GAME=VR, exists in the build you downloaded.

Official sources

1. Issues
2. License: MIT
3. OpenHUTB/hutb on GitHub
4. README
5. Releases