Forward Init_Trajectory_Status error message to queue_traj_point

[jimmy-mcelwain]

#336

All FAILURE error codes/messages from Ros_MotionControl_InitPointQueue (and further Ros_MotionControl_Init) previously got squashed into success/failure. This commit maintains the error meaning

[jimmy-mcelwain]

I am going to make changes to this for sure but I wanted feedback. I did a pretty straightforward forwarding of errors here. I think that it works fine (in my limited testing) and it's an improvement over what it was before, but there are other changes that should be made to improve clarity and durability.

The other changes that I think should happen are:
1.) At the very least, if we go with the forwarding approach I took here, in motoros2_interfaces, QueueResultEnum.msg uses UINT8 as the value and InitTrajEnum.msg uses UINT16 as the value. Those should be the same.
2.) This is more of an organization complaint. But I don't really like that sending a /follow_joint_trajectory goal (indirectly) returns an InitTrajEnum value that gets reported without modification. However, submitting a point using queue_traj_point returns either a QueueResultEnum value or an InitTrajEnum value which gets either squashed (current state of main) or forwarded (behavior in this PR). The fact that queue_traj_point can send a message that is defined in a different msg file for a different action seems messy. Especially since the messages reference "trajectory" and /start_traj_mode. I don't know what the solution would be (duplicating the relevant codes between the 2 messages, having both queue_traj_point and follow_joint_trajectory share the same msg file, or having both messages inherit some of the same constants (not sure how this would be implemented)). It should be okay to keep it the same, it just seems a bit messy/hard to follow.

[ted-miller]

At the very least, if we go with the forwarding approach I took here, in motoros2_interfaces, QueueResultEnum.msg uses UINT8 as the value and InitTrajEnum.msg uses UINT16 as the value. Those should be the same.

Agreed. My only concern is breaking compatibility of messages. But I'm not sure that can be helped.

This is more of an organization complaint. But I don't really like that sending a /follow_joint_trajectory goal (indirectly) returns an InitTrajEnum value that gets reported without modification. However, submitting a point using queue_traj_point returns either a QueueResultEnum value or an InitTrajEnum value

Personally, I'm ok with this. Ultimately, both the service and the action are initializing a trajectory. It's just a matter of "when" the points get submitted.

To me, I don't mind it. But if you have some suggestion of how to reorganize, we can take a look. Maybe some superset message for "motion init result"?

[jimmy-mcelwain]

I think that this is probably good for now. I can't really think of a better way of organizing the messages. I'll prepare a PR changing the integer types to match between QueueResultEnum.msg and InitTrajEnum.msg.

[ted-miller]

Depends on Yaskawa-Global/motoros2_interfaces#30

[jimmy-mcelwain]

I made the requested changes (amended) then rebased. I did a little bit of testing, and I think that it is alright.

[ted-miller]

Looks good.

@gavanderhoorn What are your thoughts regarding this topic:

Jimmy: This is more of an organization complaint. But I don't really like that sending a /follow_joint_trajectory goal (indirectly) returns an InitTrajEnum value that gets reported without modification. However, submitting a point using queue_traj_point returns either a QueueResultEnum value or an InitTrajEnum value

Ted: Personally, I'm ok with this. Ultimately, both the service and the action are initializing a trajectory. It's just a matter of "when" the points get submitted. To me, I don't mind it.

[ted-miller]

bumping milestone because we need updated motoros2_interfaces inside micro_ros_motoplus