Closed rgdeen closed 4 years ago
More complete/concrete proposal:
Under Articulation_Device_Parameters you'd have:
Commanded_Geometry - Specifies how the device was commanded in order to achieve the state represented in the enclosing Articulation_Device_Parameters. Commands are often at a higher level, e.g. point at this location or move to this XYZ, which is translated by flight software to the actual pose of the device. Certain forms of command are measured in a coordinate frame; this is specified by the Coordinate_Space_Reference in this class (if not present, the Coordinate_Space_Reference in the Articulation_Device_Parameters parent should be assumed).
Cardinality: if you make it part of the existing large xs:choice in ADP then it would allow a device with command only, which could be useful on occasion.
Contents of Commanded_Geometry:
<command_type> - see below, cardinality 1:1 (required)
<Device_Angle> - instance of the existing Device_Angle, card 0:1
<Commanded_Position> - see below, card 0:1
<Coordinate_Space_Reference> - instance of the existing CSR, card 0:1
Of course more could be added over time but this establishes the framework.
New Items under Commanded_Geometry:
Hey... so we have a bunch of keywords for both MSL and M20 that define how the mast was commanded to point. Which is distinct from how it actually was pointed. They feel like they belong in geom: but it's not entirely clear where, or even if they should go in a different DD.
The PDS3/ODL keywords (in case you want to look it up in the SIS) are: INSTRUMENT_COORDINATE INSTRUMENT_COORDINATE_NAME INSTRUMENT_COORD_FRAME_ID INSTRUMENT_COORD_FRAME_INDEX INSTRUMENT_COORDINATE_TYPE
Breaking those down, we basically have how the mast was commanded, and the parameters that go along with that. So reordering to make more sense in pds4 land:
Command type : parameters AZEL_ABS : azimuth, elevation AZEL_REL : azimuth_relative, elevation_relative AZ_ABS : azimuth EL_ABS : elevation JOINTS_AZEL_ABS : joint_azimuth, joint_elevation JOINTS_AZEL_REL : joint_azimuth_relative, joint_elevation_relative JOINTS_AZ_ABS : joint_azimuth JOINTS_EL_ABS : joint_elevation XYZ : x, y, z, frame name, frame index NO_MOTION : none NO_MOTION_NO_ARB : none
So where should these go?
One option would be to make another section under Geometry_Lander, something like Commanded_Geometry maybe?
Another would be to add a new subsection to Articulation_Device_Parameters - after all, we are talking about how some device was commanded to move.
The latter seems to make more sense to me at the moment. Perhaps something like:
Soooo... thoughts? Suggestions?
I somewhat dislike that az and el are named specifically in the command_type. Makes the concept less reusable for other cases. It could be that we collapse it down to fewer types, e.g. xyz, angle_abs, angle_rel, joints_az, joints_el, no_motion, no_motion_no_arb and then the presence or absence of the corresponding values in Device_Angle says which it is? Or allow all the original types and then just add more types when they come up?
BTW the difference is that az/el use inverse kinematics to point at that specific az/el, while the joint_ versions are direct commands to the motors.
Tagging @thareUSGS so he'll notice this even though it's in the geom area.