pds-data-dictionaries / PDS4-LDD-Issue-Repo

Issue repository for tracking all PDS4 Discipline Dictionary-related issues, new feature requests, and releases.
Apache License 2.0
2 stars 1 forks source link

[ldd-geom] Commanded pointing #31

Closed rgdeen closed 4 years ago

rgdeen commented 4 years ago

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:

<Commanded_Geometry>
   <command_type> enum of the "command types" above </>
   <Device_Angle> reuse existing class, values some form of az/el, az/el_relative, az/el_joint_angles, az/el_joint_angles_relative </>
   <Device_Coordinate> new class to hold coordinates, structured like Device_Angle
      <Device_Coordinate_Index>
         choice: coord_sequence_number, coord_name, coord_id
         <Vector_Cartesian_Position_Base>
         <Coordinate_Space_Reference>

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.

rgdeen commented 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:


- enumerated values, cardinality 0-1 Specifies how the device was commanded. Valid values (these should increase over time, but here's what we need now): * Angle_Absolute: Specifies an absolute pointing direction for the device. This is distinct from Joint_Absolute in that the angle is measured in a coordinate frame rather than direct joint angles. * Angle_Relative: Specifies a pointing direction change relative to the prior pointing. This is distinct from Joint_Relative in that the angle is measured in a coordinate frame rather than direct joint angles. * Joint_Absolute: Specifies absolute joint angles. * Joint_Relative: Specifies joint angles as a delta relative to the prior pointing. * XYZ: Specifies a pointing target as an XYZ coordinate in a given coordinate frame. * No_Motion: Specifies no motion from the previous observation. * No_Motion_No_Arb: Specified no motion from the previous observation, but also does not reserve the resource (thus no arbitration). * None: Unspecified commanding. (always helpful to have an escape hatch thus the None although I don't expect to use it) ---- - class derived from Vector_Cartesian_Position_Base (just like Vector_Center is). Specifies a Cartesian position used in commanding the device, such as a target XYZ location. ---- Examples ---- ``` INSTRUMENT_COORDINATE=0.0 INSTRUMENT_COORDINATE__UNIT='rad' INSTRUMENT_COORDINATE_NAME='RSM_NO_MOTION' INSTRUMENT_COORD_FRAME_ID='NONE' INSTRUMENT_COORD_FRAME_INDEX='N/A' ... No_Motion ``` ---- ``` INSTRUMENT_COORDINATE=(0.628319, 1.23918) INSTRUMENT_COORDINATE__UNIT=('rad', 'rad') INSTRUMENT_COORDINATE_NAME=('RSM_AZIMUTH', 'RSM_ELEVATION') INSTRUMENT_COORD_FRAME_ID='NONE' INSTRUMENT_COORD_FRAME_INDEX='N/A' ... Joint_Absolute Azimuth 0.628319 Elevation 1.23918 ``` ---- ``` INSTRUMENT_COORDINATE=(-0.349, -0.5236) INSTRUMENT_COORDINATE__UNIT=('rad', 'rad') INSTRUMENT_COORDINATE_NAME=('AZIMUTH', 'ELEVATION') INSTRUMENT_COORD_FRAME_ID='RNAV' INSTRUMENT_COORD_FRAME_INDEX=0 INSTRUMENT_COORDINATE_TYPE='AZEL_ABS' ... Angle_Absolute Azimuth -0.349 Elevation -0.5236 ... normal reference to ROVER_NAV_FRAME, index taken from RMC ``` ---- ``` INSTRUMENT_COORDINATE=(0.0, 0.0, 0.0) INSTRUMENT_COORDINATE__UNIT=('m', 'm', 'm') INSTRUMENT_COORDINATE_NAME=('X', 'Y', 'Z') INSTRUMENT_COORD_FRAME_ID='MAHLI' INSTRUMENT_COORD_FRAME_INDEX=0 INSTRUMENT_COORDINATE_TYPE='XYZ' ... XYZ 0.0 0.0 0.0 ... normal reference to MAHLI_FRAME, index taken from RMC ``` ---- ``` INSTRUMENT_COORDINATE=(-0.2618, 0.0) INSTRUMENT_COORDINATE__UNIT=('rad', 'rad') INSTRUMENT_COORDINATE_NAME=('AZIMUTH', 'ELEVATION') INSTRUMENT_COORD_FRAME_ID='SITE' INSTRUMENT_COORD_FRAME_INDEX=27 INSTRUMENT_COORDINATE_TYPE='AZEL_REL' ... Angle_Relative Azimuth -0.2618 Elevation 0.0 ... normal reference to SITE_FRAME, index 27 ``` ----