dronomy

# Problem Statement ## The Crisis ROS1 (Robot Operating System 1) reached end-of-life in May 2025. Yet thousands of production robotics codebases — autonomous drone flight stacks, warehouse robots, surgical systems, defense platforms — are still running on it. Security patches have stopped. Community support is gone. The clock is running. The robotics industry knows it needs to migrate. Nobody has a good way to do it. --- ## Why This Is Hard A single production MAV (Micro Aerial Vehicle) stack like KumarRobotics can have 44 packages and over 2,300 breaking API changes spanning C++, Python, CMake, and XML. The changes are not mechanical find-and-replace. They require deep understanding of two different middleware architectures: - **Node lifecycle** — ROS1 nodes are simple processes. ROS2 nodes have a managed lifecycle with explicit state transitions. - **Build system** — `catkin` is replaced by `ament_cmake` with completely different dependency and export syntax. - **Message generation** — `generate_messages()` becomes `rosidl_generate_interfaces()` with different package membership rules. - **Logging** — `ROS_INFO()` macros become `RCLCPP_INFO()` with a node logger argument. - **Parameters** — The entire parameter server API is replaced with a typed, node-local system. - **Launch files** — XML launch files are replaced with Python launch files with different syntax and semantics. - **Service calls** — Synchronous calls are replaced with asynchronous clients. - **Action servers** — The entire actionlib stack is replaced with rclcpp_action. A senior robotics engineer who knows both ROS1 and ROS2 deeply can migrate roughly one package per day. At that rate, migrating a 44-package stack takes 3 to 6 months. That is if they make no mistakes. In drone flight code, mistakes cause crashes. Existing tools — sed scripts, find-replace guides, community wikis — produce code that doesn't compile. Engineers throw it away and start over. There is no tool today that can automate this migration at scale with the accuracy required for safety-critical systems. --- ## What We Built — Problem Statement 1: Writing & Generating Code We built an AI agent that deeply understands a ROS1 codebase — its architecture, build conventions, dependency graph, and migration requirements — and generates the complete ROS2 migration at scale. **Beyond autocomplete.** The agent doesn't suggest line completions. It reads 44 packages, identifies 3,773 breaking changes across 8 semantic categories, and generates precise multi-file patches that respect the dependency ordering between packages, the naming conventions of each repo, and the build semantics of ROS2 Jazzy. **Multi-file edits from a single instruction.** A robotics engineer types one natural language instruction in the IDE — "Convert package.xml from catkin to ament_cmake, fix rosidl_generate_interfaces to use relative msg file paths" — and the agent patches CMakeLists.txt, package.xml, header files, and source files simultaneously, then runs a real colcon build to verify. **Real-world complexity.** The KumarRobotics MAV stack is not a toy codebase. It is a production autonomous flight system with SLAM, EKF state estimation, trajectory optimization, SO3 control, and a full state machine. Our agent migrated all 44 packages across all 4 repositories. 28 packages building clean, 100% success rate, verified by colcon build in a ROS2 Jazzy Docker container. **Code that won't be thrown away.** Every AI-generated patch is validated by a real compiler. If the build fails, the agent reads the error, calls o4-mini again with the error context, and iterates up to 3 times. The output is not a diff for a human to clean up — it is working, compilable ROS2 code. --- ## What We Built — Problem Statement 3: Reviewing & Deploying Code Migration at this scale cannot be fully autonomous. Drone flight code is safety-critical. An AI that migrates the wrong actionlib server could cause a mission failure. Human judgment must stay in the loop — but in a way that doesn't recreate the 3-6 month manual process. **AI-powered code review at scale.** Our Web UI presents every finding to the engineer — not as raw diffs, but as structured, categorized, context-rich review items. The engineer approves or rejects each one, adds domain-specific instructions, and the agent executes only the approved changes. 1,595 findings reviewed and approved in a single session. **IDE-native deployment validation.** Our JetBrains plugin brings the entire pipeline into the IDE the engineer already uses. Every package shows its migration status. Every AI-generated change is visible as a side-by-side diff — ROS1 on the right, ROS2 on the left, every line highlighted. The engineer can trigger a re-run on any package, type a new instruction, and watch the agent iterate in real time in the agent log panel. **Shortened feedback loops.** The cycle from "this package has an error" to "this package is clean" is under 2 minutes. The engineer types an instruction, clicks Save & Re-run, and watches the agent patch the files, rebuild the package, and update the status from `[ERRORS: 1]` to `[✅ CLEAN]`. That feedback loop used to take days. **Full auditability.** Every change is recorded — which files were patched, how many lines changed, how many iterations the agent needed, what errors remained. The migration report gives the team a complete audit trail from ROS1 to ROS2, package by package. --- ## The Result | Metric | Value | |--------|-------| | Repositories | 4 KumarRobotics MAV repos | | Packages | 44 | | Findings generated | 3,773 | | Findings reviewed | 1,595 approved | | Packages building clean | 28/28 — 100% | | Human time saved | 3-6 months → hours | | Validation method | Real colcon build, ROS2 Jazzy, Docker | --- ## Why It Matters Every drone company, defense contractor, warehouse robotics team, and research lab with a ROS1 codebase faces this exact problem right now. The migration crisis is not hypothetical — it is happening today, and the tools to solve it do not exist. The remaining work is in the .msg field naming conventions — ROS2 requires snake_case, but renaming clsID to cls_id breaks all downstream code that references it. That's an architectural decision that requires human judgment. Our platform flags it, defers it, and keeps the human in control. That's exactly what human-in-the-loop means."