Feedback wanted: Jacob's Ladder - ROS 2 + PX4 external-modes framework for UAV autonomy

Community Groups Aerial Robotics
1

Hi all,

It’s been suggested that I bring my survey to ROS discourse. I’m Lucas, an undergrad in the MATRIX Lab at the University of Maryland, and we’ve been building Jacob’s Ladder, a modular UAV command-and-control framework on ROS 2 Humble and PX4. Missions are written entirely in ROS 2 and run on PX4 external modes, so the same code flies in Gazebo SITL and on our Jetson Orin NX hardware with no rewrites.

Repo: GitHub - CursedRock17/Jacob_Ladder · GitHub

The piece I’m testing most right now is jl_mission: one C++ external mode sits behind every mission file, owns arm, takeoff, and land, and checks the setpoints coming from a Python mission runner before relaying them to PX4. The Python missions are meant to read like the code blocks elementary school kids use to learn basic actions, e.g. “takeoff”, “go forward (2.0 meters)”, “hover (5 seconds)”, “land”, just as simple Python functions with the external modes under the hood. We’re doing this because undergrads have a hard time getting into the drone space, since you need to know electrical systems, mechanical design, aerodynamics, programming fundamentals, and now AI/ML. This gives them an easier starting point, and because it’s an open-source codebase with external modes under the hood, they can expand on it as they go. Each mission runs as its own systemd service (jl_mission@<file>), so the same file goes from SITL to the Jetson unchanged.

A few runs from simulation (front approach, precision landing, approach into precision landing, and a smooth ArUco-guided planner):

Front approach

Precision landing

Front approach into precision landing

Smooth ArUco-guided planner

Where I’d most value feedback:

  • Is the main README a clear enough entry point for someone new to the project?
  • Does our use of external modes and the mode executor match how you’d structure it?
  • Is guarding the Python runner’s setpoints inside a single C++ external mode a sensible split, or would you validate them somewhere else?
  • Anything in the sim-to-real workflow (Gazebo to Jetson) you’d do differently?

Part of the code was written with help from AI tools, so blunt reviews are very welcome. Happy to share real flight video too, and I’d be glad to give a short demo at a future group meeting if that’s useful.

Thanks,
Lucas

2

Your post cuts off mid-question about external modes, so I can only respond to the README point. For a newcomer, the README would work better if it separated the three audiences you’re describing: students writing a first mission file, someone bringing up SITL, and someone deploying to the Jetson. Right now those concerns seem mixed together, which makes it hard to tell where to start. A short ordered path like “read this, run this, then edit this example” would help undergrads especially. I can’t speak to the external modes architecture itself without the rest of your question.