How can I augment a toolbox to improve its capabilities?

I am using the Robotics Systems Toolbox and its rotm2eul() function only takes in 3 possible rotation orders, XYZ, ZYX, and ZYZ. With permutations of these types there are 12 possibilities and matlab only works with a quarter of them. Adding support for the others is trivial thanks to the intelligent way the others were programmed. I only need to add 9 lines of code and remove a number of duplicated code statements in various code blocks.

[Walter Roberson]

Can the other quarter be build by composing two calls to the function?

[Andrew Roley]

@Walter, other quarter? Do you mean the other 3/4?

I think it's a paid toolbox so I don't want to get into hot water posting the full file, but here's the section where only 3 of 12 are implemented. My lines are notated with % ADDED

The function is called with only a Rotation matrix (3x3) and a 3 character string as inputs, and outputs a row vector of the euler angles, so there is not enough new data to call again unless you reconstructed a new rotation matrix in just the right way that you could deconstruct it in the allowed order, which seems like an awefully big workaround.

% Pre-populate settings for different axis orderings
% Each setting has 4 values:
%   1. firstAxis : The right-most axis of the rotation order. Here, X=1,
%      Y=2, and Z=3.
%   2. repetition : If the first axis and the last axis are equal in
%      the sequence, then repetition = 1; otherwise repetition = 0.
%   3. parity : Parity is 0 if the right two axes in the sequence are
%      YX, ZY, or XZ. Otherwise, parity is 1.
%   4. movingFrame : movingFrame = 1 if the rotations are with
%      reference to a moving frame. Otherwise (in the case of a static
%      frame), movingFrame = 0.
seqSettings.ZYX = [1, 0, 0, 1];
seqSettings.YZX = [1, 0, 1, 1]; % ADDED
seqSettings.XYX = [1, 1, 0, 1]; % ADDED
seqSettings.XZX = [1, 1, 1, 1]; % ADDED
seqSettings.XZY = [2, 0, 0, 1]; % ADDED
seqSettings.ZXY = [2, 0, 1, 1]; % ADDED
seqSettings.YZY = [2, 1, 0, 1]; % ADDED
seqSettings.YXY = [2, 1, 1, 1]; % ADDED
seqSettings.YXZ = [3, 0, 0, 1]; % ADDED
seqSettings.XYZ = [3, 0, 1, 1];
seqSettings.ZXZ = [3, 1, 0, 1]; % ADDED
seqSettings.ZYZ = [3, 1, 1, 1];

Answer 1

[Rik]

The answer by dpb is what you should do, but the answer to the question as posed is this:

Matlab is closed-source. Mathworks will probably not accept any changes to their code that they didn't write themselves. The cost is not just the edit itself, but also editing the documentation, added testing load to confirm no bugs are (re)introduced, and opportunity cost. The time spent on this function can't be spent elsewhere.

However, you can send an enhancement request which they may act on. It does happen, but they have to be convinced it is worth the cost.

[Andrew Roley]

Hadn't heard of this before, apparently it's a subset of the service request form, found by googling "enhancement request", detailed instructions here .

Thanks!

Answer 2

[dpb]

Don't have the TB in Q? so can't go look to see, but if it is an m-file, there are two ways -- you can just edit the copy in place although this is strongly discouraged.

Alternatively, shadow the function by creating a copy in a MATLABPATH location that aliases the supplied version -- it will be called preferentially before the original.

A third possiblity is to not use the builtin function directly but write a front end interface routine for it that your code calls and which, in turn, prepares the input into the form needed to call the original and then does so.

[Andrew Roley]

Yes, it's an m file. I shadowed and edited that file (actually two, the file that does the actual math, and another m file which checks for valid rotation order string, i.e. one of the 3, not the other 9 or some other string like "foobar"). This works locally as desired, but I was hoping to make a permanent change for everyone's benefit like Rik referred to.

[dpb]

Well, you could add the interface layer code solution to the FEX for others' use in that fashion, but TMW isn't going to just take user code and redistribute it even if it is a good idea. Best one can do there is to prod with enhancement request and a pointing out of the shortcoming in places like the Answers thread on wished-for improvements.

I've railed against functionality and/or klunkiness in certain user functions in responses to Q? posed here; some of which complaints go back 20 years or more since I first submitted enhancement requests for them. A few of those have actually now been implemented in the last year or two--whether the complaints made here had any effect on action now or not there's no way to know; but progress is progress, however achieved!

[Andrew Roley]

Is the "shadow" function I made with the same file and function name placed in my path the "interface layer code" solution you refer to? Sorry I'm a little ignorant here.

I also tried submitting a "improvement" suggestion, hoping maybe, just maybe, they wil take my code and add it. I didn't really do anything other than add in the missing parts of a sudoku-like puzzle.

[dpb]

No, I wouldn't suggest posting the TMW m-file on FEX; I'm sure they would soon remove it even if you could get by the original posting... :)

That would be my third option above of "to not use the builtin function directly but write a front end interface routine for it that your code calls and which, in turn, prepares the input into the form needed to call the original and then does so."

That isn't as convenient nor as efficient but provides the functionality without revealing any of the internals publicly. With it, one has a differently-named toplevel user function instead of using the TMW function name.

[Andrew Roley]

Ah, sorry. I think that's beyond my skills currently and I will have to hope for the unlikely event they incorporate my code change in a future release. Thanks for sharing the options and suggestions!

[dpb]

I would think it's basically done with what you did -- just package that. But, I don't know the code not having the TB.

[Andrew Roley]

unfortunately because the TB is hard coded to only accept a user request of the 3/12 options, in order for my current code to work without touching theirs, I'd have to plan out how to rotate from original orientation into a new one to pretend it meets their requirements, then take the answers and rearrange to match the requested order. I don't think the math is too hard, but it would just be extra time spent fixing an unnecessary problem that is practically all new work compared to what I've done so far. Adding onto the fact I don't even know what an interface routine looks like or how to make one, I'm not terribly motivated, haha.

Would it be just as simple as a new .m file/function to take in user argument, do the necessary rotation, choose the correct new order to pass to the existing function, get the returned values and return itself? The more you talk about it the more my brain is already thinking about writing it...

[Rik]

What we mean is something like the code below. The isequal function only compares two objects. This extends that

function tf=all_isqual(varargin)
%Compare all inputs to the first.
%This would be equivalent to isequal(varargin{:}) if isequal would allow multiple inputs.
tf=true;
try elem1=varargin{1};catch,end%reduce the number of times varargin{} is indexed
for n=2:nargin
    tf= tf && isequal(elem1,varargin{n});
end
end

[dpb]

I understand there's no real motivation on your end since you have a solution that works and that is the better implementation.

It would only be from your end the intellectual challenge you've outlined plus offering a tool to other users. And that may not be a very large pool, granted.

I can see you choosing either path and either is a perfectly valid choice.