Grouping: a section covering several others should follow their OR (e.g. full-width fertiliser over planter rows) #136

Sub-issue of #132. Blocked: we need a real machine (DDOP and a field test) before building this.

Problem

groupOverlappingSections (#131) only merges sections that cover the same strip: equal Offset Y (DDI 135) and equal width (DDI 67), within 10 mm. Some implements have a section that covers several others, for example a planter with:

• Boom 1: fertiliser, one section, 4.5 m
• Boom 2: seed, 6 rows × 0.75 m
• Boom 3: microgranulate, 6 rows × 0.75 m (follows the seed rows)

If these are reported as three booms with their own condensed DDIs, #131 gives each boom its own setpoint (1 + 6 + 6 sections). Grouping then merges the microgranulate rows onto the seed rows. The 4.5 m fertiliser section matches nothing, so it becomes a 7th AOG section. AOG models sections side by side and can't represent one that overlaps the other six. AOG would therefore be set up wrong, and the fertiliser would be driven by whatever AOG thinks section 7 is.

Proposal: containment

Each section covers the strip [Y − width/2, Y + width/2] (with the same 10 mm tolerance).

For the planter above, AOG sees 6 sections (AOG 1–6 = rows 1–6, seed and micro grouped), and the fertiliser is on while any row is demanded. Two fertiliser half-booms of 2.25 m would each follow the OR of their own 3 rows.

Details:

• section_layout: the map becomes "set of AOG sections per implement section". Ordinary and grouped sections get a set of one; a covering section gets the set it covers. It stays a pure function, unit-tested against a synthetic pool and later the real DDOP.
• update_section_states: a section's setpoint is ON if any AOG section in its set is demanded.
• Heartbeat (0xF0): covering sections don't feed AOG's bits. The rows report the coverage themselves, so a lifted fertiliser boom can't make a row look like it's working, and the reverse.
• Alert AOG when a section is commanded on but reports off (and the reverse) #134: a covering section commanded on but reporting off still raises the mismatch alert.
• Stays behind groupOverlappingSections (default off). The mapping log (geometry gives N AOG section(s) …) shows covering sections, e.g. 7->(1-6).

What we know so far

The only Amazone Precea DDOP we have (AMAZONE_PRECEA_4500_6sec_2booms.ddop in the object pool collection, from #35, sw NW110-M.012) does not look like this. It has one Function, "seed release point" (element 4, the only element with DDI 160/290/161), with 6 row Sections. Seed, fertiliser and microgranulate are three Bins under that same Function, plus a separate tramline Function. For that pool #131 behaves exactly like develop (one owner, 6 AOG sections), and the fertiliser/microgranulate behaviour (following the lift height, copying the seed rows) happens inside the Amazone ECU.

So we don't yet know whether any machine reports a covering section as its own boom.

Needed before building

• A DDOP from a machine that has a covering boom with its own section and condensed DDIs (candidates: a Precea with a different software or configuration, planters with front-tank fertiliser, seeders with a full-width fertiliser or slug-pellet boom).
• The TC log from the Basic multi-boom support; collapse identical/overlapping sections #131 build with that machine connected, showing the requested Offset Y and width per section (Element N reports …).
• A field test: rows switching on and off individually, with the covering boom following the OR.