refactor: send the set-home command as COMMAND_INT

[rafaellehmkuhl]

Summary

DO_SET_HOME went out as a COMMAND_LONG, which carries latitude and longitude as floats and has no frame field, leaving the altitude reference implicit. COMMAND_INT carries the position as scaled integers and states the frame explicitly, which is what lets the user pick an altitude reference when setting a home point.

Two commits:

Send the command as COMMAND_INT. setHomeWaypoint now goes through sendCommandInt. The parameter slots line up with the previous sendCommandLong call, so param1 stays 0 (use the coordinates carried by the command rather than the vehicle's current position) and lat/lon/alt keep their positions. sendCommandInt hardcoded MAV_FRAME_GLOBAL, so it now takes a frame, still defaulting to MAV_FRAME_GLOBAL so the existing goTo caller is untouched.

Default the set-home altitude to home-relative. Both call sites pass an altitude of 0. Under MAV_FRAME_GLOBAL that means 0 m AMSL, so setting a home point was putting home's altitude at sea level — wrong for any vehicle operating at elevation, and it skews return-to-launch altitudes. setHomeWaypoint now defaults to MAV_FRAME_GLOBAL_RELATIVE_ALT, where zero resolves against the current home: home moves horizontally and its altitude is left alone.

This is also groundwork for the dialog that will let the user choose the frame and altitude explicitly, which is where a non-default frame will first get passed in.

Test plan

• Set home from the map context menu → vehicle accepts the command and home moves to the clicked point.
• Confirm on the wire (mavlink2rest / autopilot logs) that a COMMAND_INT is sent with MAV_FRAME_GLOBAL_RELATIVE_ALT and lat/lon arrive scaled by 1e7, not zeroed.
• With the vehicle at meaningful elevation, set home and confirm its altitude is preserved rather than dropped to sea level, and that RTL altitude behaves accordingly.
• Verify the target firmware actually honours a home-relative frame for DO_SET_HOME (ArduPilot's handling has varied by version and vehicle) — if it rejects the command, the default should move to MAV_FRAME_GLOBAL with a real altitude rather than zero.
• Drag the home marker → same result.
• Use "go to" on the map → DO_REPOSITION still behaves as before, confirming the sendCommandInt frame default did not regress that caller.

Fixes #2871.

[github-actions]

Automated PR Review (Claude)

0. Summary

Verdict: READY TO MERGE

This PR switches the DO_SET_HOME MAVLink command from COMMAND_LONG to COMMAND_INT, which carries lat/lon as scaled integers and includes an explicit reference frame field. The new frame parameter (defaulting to MAV_FRAME_GLOBAL) is threaded through sendCommandInt, MAVLinkVehicle.setHomeWaypoint, and the mainVehicle store wrapper. All existing callers (goTo, both map-based setHomeWaypoint call sites) omit the new parameter and therefore pick up the default, preserving current behavior. Clean, minimal, well-scoped change.

1. Correctness & Implementation Bugs — ✅

2. AGENTS.md Adherence — ✅

3. Security — ✅

4. Performance — ✅

5. UI / UX — ✅

6. Code Quality & Style

6.1 nit — src/stores/mainVehicle.ts JSDoc for setHomeWaypoint: the existing @param tags for coordinate and height lack {type} annotations (they use { [ number, number ] } and { number } with unusual spacing but that is pre-existing). The new @param { MavFrame } frame follows the same style, which is fine. However, the @returns tag is { Promise<void> } — note that the corresponding @returns on the MAVLinkVehicle version omits a tag entirely (the JSDoc says @returns {Promise<void>}). Both are acceptable per the eslint config, just calling out the inconsistency for awareness. No action required.

7. Commit Hygiene — ✅

Single logical commit with a descriptive refactor: subject and a body explaining the rationale. Branch name issue-2871-set-home-command-int follows the convention. Clean.

8. Tests

8.1 minor — No automated test covers the sendCommandInt → setHomeWaypoint path. The change is straightforward parameter threading, and the PR body includes a manual test plan exercising it on hardware, which is reasonable for a MAVLink command path. Still, a unit test asserting that setHomeWaypoint builds a COMMAND_INT message (not COMMAND_LONG) with the expected frame and scaled lat/lon would catch future regressions cheaply.

9. Documentation — ✅

10. Nitpicks / Optional

10.1 nit — In sendCommandInt, the new frame parameter is appended after z, making it the 9th positional parameter. This is already a long positional list. A future improvement could be to accept an options object for the less-common parameters, but that is out of scope here and the default keeps it ergonomic.

Generated by Claude. This is advisory; a human reviewer must still approve.

[ES-Alexander]

Would be nice if this was less hard-codey, so it's not necessary to loop up the spec to understand some of the fields.

Suggested change

	await this.sendCommandInt(MavCmd.MAV_CMD_DO_SET_HOME, 0, 0, 0, 0, coordinates[0], coordinates[1], altitude, frame)
	await this.sendCommandInt(
	MavCmd.MAV_CMD_DO_SET_HOME,
	0, // Use the specified location, not the vehicle's current location
	0, 0, 0, // Don't set roll/pitch, and set north(?)-facing yaw
	coordinates[0], coordinates[1], altitude,
	frame // Reference frame for the coordinates and altitude
	)

Having checked the spec, perhaps we should be using NaN values for roll/pitch/yaw, so we don't accidentally set a specific heading for the home location that the user doesn't control? 0 and NaN are equivalent for roll+pitch, but feel less intuitive as a non-valid sentinel value, and masks the fact that 0 for yaw is interpreted explicitly instead of ignored.

For future reference, I suspect we'll want to provide at least some method for the user to specify the vehicle's current location as its new home.

[ES-Alexander]

height seems unclear given there's no requirement for the value to be above the home (and in fact Sub vehicles typically operate below a surface-based home).

If this method is general we should stick with MAVLink's altitude terminology for clarity and consistency. If instead we're operating on a filtered down subset of use-cases perhaps we could call this distanceAboveHome or similar, though I imagine it will be a challenge to find a really nice term.