So my question is - how should I go about getting MoveIt to reorganize the joint order? Is it even possible?
The short answers would be: "you can't" and "no".
However, it organizes the joint data in the JointTrajectory message differently [..] which seems to be alphabetical
Exactly.
I saw while doing some research online that a parameter called controller_joint_names can be loaded that lists the joints in the order you want them. However, it didn't seem to have any effect.
That parameter isn't used by MoveIt. It's a parameter particular to the nodes in the industrial_robot_client package.
As to your problem: the expectation is for every driver to take in the JointTrajectory message, look at the joint order and if you need a different one for whatever reason, your driver should calculate a mapping between the values in each JointTrajectoryPoint and your desired order.
You could of course also in-place re-order everything. That would be up to you.
Edit: you could of course wonder why this is not supported. I can't give you an authoritative answer, as I wasn't around when this was designed/implemented, but I can come up with a good rationale a posteriori (which goes further than just MoveIt).
Depending on a certain order of data in a message has two big disadvantages:
- it complicates interpreting message data: in this particular case, the names of the fields are present in the message, but this is not always the case. If a specific order is expected or required, this order would then have to come from "outside". As this "outside" may not always be available, relying on it would mean that messages cannot be interpreted stand-alone (ie: without requiring anything else besides the message).
- it complicates replacing components with others: different components could require different orders of data. Replacing one component with another would then require reconfiguration of (several) other components. At the very least this introduces a step which could be forgotten easily, potentially leading to some surprises the first time the new configuration is started, or worse, dangerous behaviour.
Requiring this order essentially increases coupling, which is undesirable in component based systems (for any software architecture really).
Delegating the responsibility of re-ordering incoming data to whatever desired order to the consumers of messages avoids all of this, as consumers (ie: nodes) are free to do whatever they want internally, as long as those details do not leak to other parts of the architecture.
