Problem 44819. Relative pose in 2D: problem 1
We consider a world reference frame denoted by {0} which has its x-axis pointing east and its y-axis pointing north. There is a robot with an attached body-fixed coordinate frame {B} whose origin is in the centre of the robot, and whose x-axis points in the robot's forward direction.
With respect to the world frame origin , the robot's centre is at a distance of 123m in the x-direction and -74.6m in the y-direction. The car's heading angle is exactly SSW.
Write a 3x3 matrix homogeneous transformation matrix that expresses the pose of the robot frame {B} with respect to the world frame {O}.*
Solution Stats
Problem Comments
-
7 Comments
The test suite needs to call the function, so that the matrix T will be available for testing.
Ooops! I see now that the function is called, but it looks like a program comment "%%T = user_function"
That's weird, it shows as a %% comment, but in the problem editor it is not. I've asked MathWorks about this.
A %% needs to be added before the first line. Otherwise, the server parses that first line of the test suite as a comment. I've fixed it here; feel free to fix this problem wherever else it occurs in problems you've created.
@goc3 that broke my test! Seems there is some implicit scoping rule, by adding the %% it means that T is not available in subsequent %% cells. Fixed it by calling the user function multiple times. This stuff is not well documented: the scoping rules, the need for a leading %% etc.
Sorry for any confusion that may have been caused. Yes, there may be a need for more detailed explanations of some site functioning, but that is beyond my power. For what it's worth, the scoping rule is consistently applied for all problems on the site: variables called within each test case are only available to that test case. I (and many other problem creators) end up repeating lines for any required variables within each test case.
The %% is an issue because it is so poorly documented and hence poorly understood (or even not understood). The following seems to be how it works. [Note: in the following I will use "↲" to indicate the end of a line in the code/output.]
~~~~~~~~~~
Creator writes this TEST SUITE:
~~~~~~~~~~
-----
commandA↲
commandB↲
↲
%% test 1↲
commandX↲
↲
%% test 2↲
commandY↲
-----
~~~~~~~~~~
Cody RUNS the following tests:
~~~~~~~~~~
Test 1: (i) commandA; (ii) commandB; and (iii) commandX.
Test 2: (i) commandA; (ii) commandB; and (iii) commandY.
~~~~~~~~~~
Cody DISPLAYS the following output:
~~~~~~~~~~
-----
%%commandA↲
commandB↲
↲
%% test 1↲
commandX↲
↲
[output from commandX only]↲
↲
%% test 2↲
commandY↲
↲
[output from commandY only]↲
↲
-----
~~~~~~~~~~
Notice: (i) any commands before the first %% [namely commandA and command] are run at the beginning of every test; (ii) output of any commands before the first %% is suppressed [never displayed]; (iii) for the player, a spurious "%%" is displayed on the first line of the Test Suite if there were any commands before the first "%%".
It is actually a very clever structure for Problem Creators writing a Test Suite. Therefore I'd be keen to retain it. See e.g. https://www.mathworks.com/matlabcentral/cody/problems/44655
The annoyances are: (i) lack of documentation; (ii) suppression of output; and (iii) insertion of a spurious "%%" in the display.
Although none of these three issues affect the running, they cause a lot of confusion and misunderstanding.
Solution Comments
Show commentsProblem Recent Solvers149
Suggested Problems
-
1714 Solvers
-
461 Solvers
-
Check if number exists in vector
11682 Solvers
-
1510 Solvers
-
Relative points in 2D: problem 2
62 Solvers
More from this Author16
Problem Tags
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!