mavschema.xsd - max, min, increment on fields

[hamishwillee]

For exactly the same reason that they are useful on parameters it would useful to have max, min, increment on fields - i.e. to restrict values as displayed in the UI and to make it easier to enforce ranges and test ranges in messages.

FYI @peterbarker @amilcarlucas , a high level view on the current schema is shown below prior to this PR. Are there any that we should have in both other than these? I don't think so, except possibly for decimalPlaces (not in any hurry to add it)

Another change we might make is to restrict some of these on enum - i.e. you shouldn't specify units if you have an enum and so on. I don't see it as a risk, but as a nice to have. OK?

---

MAV_CMD

• attributes

  • value (an id number)
  • name
  • hasLocation | isDestination

• wip | deprecated | superseded (?)

• description

• param (7)

  • description
  • attributes
    • index [1-7]
    • label
    • units
    • enum
    • decimalPlaces
    • increment
    • minValue
    • maxValue
    • reserved (for future use, default false)
    • default (default value of 0 or NaN, intended for reserved params).

MESSAGE

• attributes:
  • id
  • name
• wip | deprecated | superseded (?)
• description
• field (s)
  • type
  • name
  • enum (or units)
  • display ('bitmask')
  • units
  • print_format (?)
  • default (?)
  • instance
  • invalid

ENUM

• attributes:
  • name
  • bitmask (true | false)
• wip | deprecated | superseded (?)
• description
• entry (s)
  • attributes:
    • value (id)
    • name
  • description
  • wip | deprecated | superseded (?)

[hamishwillee]

@peterbarker Pretty please?

[peterbarker]

I'm a bit concerned by the proposed uses.

We've found with ArduPilot parameters that people often need to set parameters to values outside the expected range (sometimes as technology changes, sometimes as weird implementations are created). Absolutely constraining the input values (as MissionPlanner does in many interfaces!) causes people grief. OTOH, this is a UI issue rather than a standards thing.

minValue/MaxValue also tend to suffer when flag values are also in play.

I'm going to merge this anyway as the "make it orthogonal" argument seems to be compelling.

[hamishwillee]

@peterbarker Thanks very much. Generally we design parameter end points with a particular set of use cases in mind. If someone says this doesn't work we probably missed that use case and need to reevaluate. But either way, it is always possible to make a range bigger, but it is bloody hard to push the genie back in the bottle.

The problem here will be if we start using these for existing APIs where these changes have already happened. In that case we'll have a bit of churn possibly if there is enforcement. We'll have no choice but to expand them then. But I'd rather know.