I also like having a constraint model as opposed to a type field.
I imagine there are two main types of constraints that any planner cares about:
-
kinematic and other hardware-related constraints (max possible accel, axis of possible actuation, max curvature, etc)
-
behavior constraints/costs (ie software limiting of max velocity, acceleration, jerk, etc) which may change over time like when in different modes or domains.
Since we are discussing the interface between a “higher” level controller and the “lower” level actuation, I’m going to assume that it’s only the kinematic/hardware constraints that are relevant. In your example, I would say that a “preferred” acceleration belongs in a behavior constraint list.
So a couple of questions that pop out are:
- Should all constraints be together?
- Should constraints be set through a configuration file or a message?
It appears the REP sets these in a goal message? My initial reaction was “the URDF sounds like a good place to put kinematic constraints” but I can see use-cases where a separate configuration would be desired. The URDF would also only work for kinematic/hardware constraints and a separate message would be needed to describe desired behavior constraints.