Suggestion: use a different name for 'tcp_frame'

[gavanderhoorn]

TCP (Tool Centre Point, or Tool Control Point) is terminology which is pretty much mostly used in industrial robot contexts.

It would be good if we could make these messages somewhat more generic: the goal of the trajectory message seems to be able to encode how a specific link should be moved through a Cartesian space by specifying a list of points in that space with associated constraints on velocity, acceleration (and potentially jerk: #3). That does not necessarily need to be a industrial (serial) manipulator (uavs come to mind, but perhaps anything which can be controlled in a similar manner might be relevant).

As naming is important, including tcp as a prefix seems like it precludes the use of this message in those contexts (not really of course, but it would be strange to set a field called tcp_frame for a robot which does not have a TCP, or perhaps only a single controllable link).

This 'complaint' about tcp_frame is a bit weak, as there is also a posture field which may not be applicable either for other types of robots, but it may still be worth it to consider using a different name for the controlled link (or the link for which the Cartesian trajectory describes the desired state over time).

[fmauch]

Good point and I fully agree.

[gavanderhoorn]

I've seen tip used, but that still sounds like something which would be "at the end" of something else.

In "my" messages, it's simply child_frame_id, which may also not be perfect.

[fmauch]

I actually think, controlled_frame would be a nice name. @gavanderhoorn You did not directly suggest it, but it caught my attention, when I read it.

[gavanderhoorn]

Hm, that could work.

child_frame_id reminds me of tf/Transform though, which also represents a Cartesian point in a way.