Cursor + ArduPilot — look up settings, write them down, apply
We don’t configure the Pixhawk from memory. We look up settings, write them down, and reuse that as input.
Somewhere mid-stack I wondered: is ELRS already on SERIAL2_PROTOCOL = 23? I thought yes. The backup said no. That moment — “I think” vs “the dump says” — is exactly why we work this way.
ArduPilot is a big list of parameters on the FC. You can fetch and change that list — see ArduPilot settings. On this build we do it with Cursor: the agent reads docs and backups, proposes what’s next, and keeps the documentation current. Mission Planner writes to the board. Cursor never flashes anything itself.
Problem we’re solving
On the Pixhawk 6X Mini many things must be right: GPS, CAN, ELRS, battery, later OSD. From memory that fails. We wanted to:
- Look up settings (wiki, Holybro, ELRS docs).
- Document them in the build docs (parts + progress).
- Use those docs plus a param backup as input for the next step.
How / why / which problem: less guessing, a trail in git, and a checklist before we fly safely.
How we do it
1. Look up
We read the official source. Examples: ArduPilot DisplayPort, CRSF/ELRS, Holybro setup for H-Flow or F9P.
Cursor helps: “what should SERIAL2_PROTOCOL be for ELRS?” → answer with source + value. Not “feels like 23”.
2. Document
Every choice lands in a part post or the progress documentation. Short. With params. With links.
Checklist: ArduPilot settings — progress.
Done / todo / later. Plus the real values from our dump.
3. Backup from the FC
In Mission Planner: fetch parameters → Save to file.
Files in the repo:
docs/firmware/param-backups/pixhawk6x-mini-latest.param— full listpixhawk6x-mini-YYYYMMDD-….param— dated snapshot
Cursor (and we) read that dump. So we know what’s on the board. Not what we “think” is on it.
4. Use as input
Next question in Cursor: “ELRS is still todo. Which params should we set, given the backup?”
The agent:
- reads the backup (
SERIAL2_PROTOCOLis still 2, not 23); - reads ELRS setup;
- proposes the param set;
- updates the progress documentation.
Then we write those params in Mission Planner (Write Params). Props off. Test. New backup.
What we locked into the repo
| What | Where |
|---|---|
| Skill | .cursor/skills/ardupilot-params/SKILL.md |
| Rule | .cursor/rules/ardupilot-params.mdc |
The skill says: read the param backup + part 27 first. Don’t invent params from thin air. Keep NL/EN documentation and status updated.
Port map we keep repeating (so nobody mixes TELEM1/2): TELEM1 = LD-06, TELEM2 = ELRS, CAN = F9P + H-Flow, GPS2 = M9N.
What it buys us (and what it doesn’t)
Yes: no guessing (backup = truth), a trail in docs + git, faster next steps because Cursor knows the stack, less repeated wiki work, safer checklist before first flight (ELRS, 6S batt, LD-06, …).
No: Cursor does not flash the FC. No inventing params without a source or backup. No vague “phase” jargon — we say what’s on the board now, and what’s left before we can fly safely.
Short: we “program” ArduPilot by managing params. Cursor reads. We (via Mission Planner) write.
Read next
Choice log
Skill + rule in .cursor/; progress in part 27; truth in .param dumps. Not from memory. That SERIAL2 moment was enough persuasion.
Photos