I build drone autonomy software for a living. Vision-only navigation, perception, control, the kind of work where you spend most of your day not flying a real aircraft, because crashing a real aircraft into a wall to test a bad line of code is expensive and slow. Simulation is where the actual work happens.And that is exactly where I keep hitting the same wall.Here is the honest sequence for a beginner who wants to test a drone control algorithm in 2026. First, install Ubuntu, then dual-boot it, or fight a virtual machine. Then install ROS, and the specific ROS distribution that matches the specific simulator version you picked. Then compile a game engine, or download several gigabytes of pre-built environments. Then chase GPU drivers. Then, somewhere around hour three or hour thirty, if nothing broke, you finally get to write the one function you actually cared about.Most people never make it to hour three. They bounce off the setup and conclude that drone software is "not for them." That conclusion is almost always wrong. The setup was the problem, not their ability.I wanted to remove the setup.The four wallsWhen I map out why existing simulators are so hard to get started with, it comes down to four recurring barriers.The operating-system wall. The serious, research-grade simulators are Linux-first, and often Linux-only in practice. Gazebo, PX4's software-in-the-loop, ArduPilot's SITL that is all excellent, all assuming you are comfortable in a Linux terminal with ROS on top. If you are a student on a Windows laptop or a school Chromebook, you are already locked out before you begin.The installation wall. Even on the right OS, "installation" frequently means compiling from source, resolving dependency conflicts, and downloading enormous world files. This is fine for a professional who already crossed that bridge years ago. It is a brick wall for a curious newcomer.The hardware wall. A lot of these tools assume a discrete GPU because they were built on heavyweight game engines for photoreal rendering. That is a real cost, and it quietly excludes a large part of the world that is doing perfectly good engineering on modest machines.The paywall. The moment you drift toward polished, beginner-friendly tools, many of them cost money, or a one-time purchase, or a recurring subscription. The commercial FPV trainers used for pilot muscle memory are paid products. The friendliest educational drone-coding platforms are subscription services aimed at schools. Accessibility and "please enter your credit card" do not sit comfortably together.There is a fifth barrier that is less about setup and more about trust: abandonment. The clearest example is AirSim. Microsoft Research created it in 2017, and for years it was the default free simulator for aerial AI experimentation. Then, around 2022, Microsoft announced it would archive AirSim in favor of a commercial successor called Project AirSim. The original was frozen but it still works, but receives no new features, and the successor's path was rocky enough that the project effectively went quiet before later re-emerging under a different steward. If you built your research on top of the flagship free simulator, the ground moved under you. That risk is real, and any new project, including mine, has to answer for it. I'll come back to that.Where I'm sitting when I say thisI'm a solo founder working out of Negombo, Sri Lanka. I mention that not for color but because it shapes the problem I actually see. The assumption baked into a lot of robotics tooling is that everyone has a beefy Linux workstation, a fast connection to pull down gigabytes of assets, and someone nearby who has done the setup before. Step outside that assumption, which is most of the world, and the on-ramp to drone autonomy gets steep fast.So the design goal became almost embarrassingly simple to state: make testing a drone algorithm as easy as opening a URL.Open-source, so nobody is priced out and nothing gets archived out from under you without the community being able to carry it forward. Browser-native, so the operating system stops mattering including, Windows, macOS, Linux, a Chromebook, whatever you already own. Zero-install, so the first thing you do is fly, not troubleshoot. That is SkySim.But not a toyHere is the part I care about most, because it's where "runs in a browser" usually becomes a red flag.There are already drone simulators in the browser. I went looking, and I found them: open-source FPV trainers built on Three.js that help human pilots build stick-and-rudder muscle memory, and slick educational platforms that teach kids to drag code blocks and watch a quadcopter respond. Those are genuinely good at what they do. But they are not built to test the algorithms that fly autonomous drones. They are flight games and teaching toys, and I mean that descriptively, not as an insult.SkySim's ambition is different. Underneath the browser front door, it runs real aerodynamics computed in C++20, blade-element rotor modeling, ground effect, vortex ring state, an ISA atmosphere model, turbulence. And critically, it can hand the vehicle over to actual flight-controller firmware: ArduPilot, PX4, and Betaflight, through the same interfaces those stacks use on real hardware. The point is that the control logic you test in the sim is the control logic you deploy on the drone. Same firmware. Same code path.The longer arc, that the one this whole series is really about, is a sim-to-real loop. Run the real onboard AI, unchanged, against simulated sensors and a simulated world; use the sim to test it and to generate labeled data; use that data to make the real drone smarter. A simulator that is trivial to open, but serious enough that what you learn inside it transfers to a physical aircraft.The strongest arguments against doing thisI try to argue against my own projects before anyone else gets the chance, so here are the objections I think are actually good."Browser drone sims already exist, and this isn't new." Correct, and I won't pretend otherwise. What I couldn't find was one tool that combines all of what I need: zero-install and open-source and research-grade physics and real firmware-in-the-loop and a clean interface for testing autonomy algorithms. The existing browser sims each pick one or two of those. The gap is the combination, not any single feature."The browser can't do serious physics or machine learning." Also fair, and I refuse to fudge this. Heavy ML training and full firmware SITL run in a native agent server, not in the browser. The browser tier is for interactive flight and lighter, classical control, the on-ramp and the demos, and while the demanding work runs locally against the same physics core. Being honest about that split is more useful than promising the browser can do everything, because it can't, and you'd catch me the first time you tried."Why not just improve Gazebo or PX4 SITL instead of building another simulator?" Because those tools are excellent for people who already climbed the setup hill, and I don't think the answer to a bad on-ramp is a slightly better mountain. I'm not trying to replace them and SkySim is designed to interoperate with that ecosystem, and a chunk of the work in this series is about contributing upstream to exactly those projects. The niche is the first hour, not the thousandth."You're one person and it's non-commercial. So, what happens when you lose interest? Isn't this just the next thing to get archived?" This is the sharpest objection, and the AirSim story is the reason it lands. My honest answer is that a permissive open-source license and a real contributor community are the only credible defense, and not promises from me. That's why I've deliberately kept SkySim separate from my commercial work and why recruiting contributors is a first-class goal rather than an afterthought. Whether it works is genuinely still an open question. I'd rather say that plainly than pretend a solo project is guaranteed to last.What's coming in this seriesThis first piece is the "why." The rest will be the "how," and I intend to keep it concrete and buildable rather than abstract:The architecture: how a C++20 physics core, a game engine, and WebAssembly fit together so the same simulation runs natively and in the browser.The physics: what blade-element theory, ground effect, and vortex ring state actually mean for a quadrotor, and where I've marked the honest placeholders that still need validated math.The firmware bridges: connecting to ArduPilot, PX4, and Betaflight through the same protocols real drones use, and the bugs I hit getting the wire formats right.The agent interface: a clean, gym-style API so you can point a reinforcement-learning agent or a classical controller at the sim and start testing.Going upstream: what it takes to contribute to established robotics ecosystems, and why I think that's the responsible way to build here.If you've followed my earlier writing on [LINK: vision-only / VSLAM navigation] or on [LINK: reverse-engineering an RC drone into an autonomous platform], this is the same thread pulled further: I keep trying to shrink the distance between "I have an idea for how a drone should think" and "I can test it tonight."Try it, or better, break itSkySim is on GitHub, open-source, and it runs today: https://github.com/vishwagw/Sky-Sim-drone-simulator-3.0. You can fly it, read the code, and the part I actually want, is to tell me where it falls short. I'm looking for contributors, not just users. If any of the four walls I described are ones you've hit yourself, you already understand the project better than most, and I'd like your help tearing them down.