i cannot find the definition of scipy's coordinate system.
i have tried several values (assuming a right hand system) but got a strange result.
for example:
from scipy.spatial.transform import Rotation as R
R.from_euler('zyx', angles=np.array([90,0,0]), degrees=True).as_matrix()
[ [ 0., -1., 0.], [ 1., 0., 0.], [ 0., 0., 1.]]
meaninig the counterclockwise rotation about the z axis (true for a right hand system) is inverse (meaning a left coordinate system)...
where can i find the definition??
Thanks!!!
The full documentation for Scipy's Rotation module can be found here. For your problem in particular, I am not sure there actually is a problem. Looking at Wikipedia, a 90-degree rotation is indeed counter-clockwise so that a vector originally aligned with the x-axis becomes aligned with the y-axis. This, I believe, is in agreement with the result of the code below.
from scipy.spatial.transform import Rotation as R
point = (5, 0, -2)
print(R.from_euler('z', angles=90, degrees=True).as_matrix() # point)
# [0, 5, -2]
In short, I think giving positive angle means negative rotation about the axis, since it makes sense with the result.
Normally, positive direction of rotation about z-axis is rotating from x-axis to y-axis; negative direction is from y to x.
The Documentation shows that using from_euler to initial a counter-clockwise rotation of 90 degrees about the z-axis is
R.from_euler('z', 90, degrees=True)
I guess "the counter-clockwise rotation about z-axis" from doc means "negative direction about z-axis" instead of "positive direction about z-axis".
Related
I'm currently trying to learn how to use the gravity models that Matlab's 'gravitysphericalharmonics' library has. In this documentation: https://www.mathworks.com/help/aerotbx/ug/gravitysphericalharmonic.html#mw_3bdd1e99-46be-4fd5-8b7c-6dd710546616
It gives us two examples:
Calculate the gravity in the x-axis at the equator on the surface of Earth. This example uses the default 120 degree model of EGM2008 with default warning actions.
gx = gravitysphericalharmonic([-6378.137e3 0 0])
Calculate the gravity at 25,000 m over the south pole of Earth.
[gx, gy, gz] = gravitysphericalharmonic([0 0 -6381.751e3],'EGM96','Error')
Here's my question, how did they get -6381.751e3 for the second question if they're just finding the gravity 25,000m above the surface of Earth? If Earth's radius is ~6378.137e3 meters, then calculating the gravity at 25,000m above Earth would just be the radius + 25,000 meters right?
Lastly, I wanted to just ask someone with more knowledge about this module why it was -6378.137e3 m for the first question. If we're taking the coordinate from just the surface of Earth, wouldn't that number have to be positive?
Sorry if this doesn't make any sense, I'm new to this stuff and I really want to learn! Thanks!
The first example uses a 3D position vector, in a coordinate system with its origin at the center of the planet (Earth). The position vector[-6378.137e3 0 0] is on the equator, as is [6378.137e3 0 0] (they are on opposite sides of the world). Any other position vector with magnitude 6378.137e3 and a Z component (the third number) of 0 would also be on the equator.
The Earth is not a perfect sphere; it is an oblate spheroid. The radius at the equator is 6378.137 km, but the radius at the poles is 6356.752 km. Their documentation is not great here, but they have arrived at the position vector in the second example by taking this polar radius and increasing the magnitude of the vector by 15 km. The Z component is negative because this example is at the South Pole; if the Z component were positive, it would be at the North Pole. Because it is negative, they have to add -15 km to get to a point that is 15 km above the surface (but if you were looking at a globe, and holding the globe so that north is up, that point would be below the globe).
They have probably used examples with negative values in the position vector precisely to ensure that people ask themselves the kinds of questions that you are asking.
The aerospace toolbox also provides a function ecef2lla to convert these position vectors into latitude, longitude, and altitude, which may help you understand them.
I am having doubt to the used equation in the function of imgradient.
In the line of 127:
Gdir = atan2(-Gy,Gx)*180/pi; % Radians to degrees
Why the Gy have to be negative?
The y-axis is inverted in images (it increases downward instead of upward). This causes the angles to increase clockwise instead of counter-clockwise as you're used to. By flipping the y component of the gradient, this line computes an angle in the "normal" sense.
Using the graph that #Dan linked in his comment:
In this graph, y increases upward, and angles increase counter-clockwise. In an image, the coordinate system is flipped. This leads to counter-intuitive angles. Hence they invert the y axis to compute the angle.
I've already asked this question in a different way here; Swift-Setting a physics body velocity by angle but the three attempts to answer it were unfortunately not exactly what I'm looking for, although I'm grateful for what they taught me anyway. I decided that I should simply rephrase my question with an example and further explanation instead of perpetuating a discussion via comments. So here it is.
Imagine I have an SKNode positioned in the centre of the screen. Let's say this is a ball, so any rotation action on it is not visible. I would need a way to have a random angle selected, and have said SKNode rotate to it, and then continuously move in the direction determined by the aforementioned angle from its original position in the centre of the screen, until, say, the edge of the screen.
I know how to determine the random angle, have the SKNode rotate to it, and have it stop at the edge of the screen. Hopefully with this example what I need is clearer, a way to simply have an SKNode move forward, but on an angle determined by a single variable, and not a velocity determined by two, dx and dy.
Thanks in advance.
To do this, you just need to use some trigonometry!
When zRotation is between 0 and 90, you don't need to do anything to the angle except converting it to radians. Just call tan(radianAngle). Now tan will return how much should the node move in the y axis when it moves by 1 in the x axis. If you learned trigonometry before, you should understand what I'm saying. If you have not learned trigonometry, learn it. :)
Let's say the node's zRotation is 60 degrees, which is π/3 radians. Pass that into tan and you get √3. This means your dx and dy parameters in SKAction must be in the ratio of 1 : √3 in order to make the node move in the direction of 60 degrees.
When zRotation is between 90 and 180, you need to first subtract the angle from 180, then convert it to radians. Again, pass that to tan and the return value is how much your node should move in the y direction when it moves by -1 in the x axis. The dx : dy ratio is now -1 : tan(angleInRadians).
When zRotation is between 180 and 270, subtract 180 from that angle and convert it to radians. The dx : dy ratio is -1 : -tan(angleInRadians).
Lastly, a zRotation bewteen 270 and 360, subtract the angle from 360 and convert it to radians. The dx : dy ratio is 1 : -tan(angleInRadians).
Just before you convert the angle to radians, check if the angle is 90 degrees. If it is, please hard code the dx and dy because tan(M_PI / 2) is undefined.
My math is too rusty to figure this out. I want to derive the onscreen angle (the angle as seen on the 2d screen) of a 3d vector.
Given the x and y rotation of a vector (z rotation is zero and doesn't mstter), what does the angle on screen look like?
We know when y is zero and x is positive, the angle is 90. When y is zero and x is negative the angle is -90. When y is 90, for any value of x, the angle is 180. When y is -90, for any value of x, the angle is 0.
So what the formula here so I can derive the angle for the other values of x and y rotation?
The problem, as stated, doesn't make sense. If you're holding z to zero rotation, you've converted a 3D problem to 2D already. Also, it seems the angle you're measuring is from the y-axis which is fine but will change the ultimate formula. Normally, the angle is measured from the x-axis and trigometric functions will assume that. Finally, if using Cartesian coordinates, holding y constant will not keep the angle constant (and from the system you described for x, the angle would be in the range from -90 to 90 - but exclusive of the end points).
The arctangent function mentioned above assumes an angle measured from the x-axis.
Angle can be calculated using the inverse tangent of the y/x ratio. On unity3d coordinated system (left-handed) you can get the angle by,
angle = Mathf.Rad2Deg * Mathf.Atan(y/x);
Your question is what will a 3-d vector look like.
(edit after posted added perspective info)
If you are looking at it isometrically from the z-axis, it would not matter what the z value of the vector is.
(Assuming a starting point of 0,0,0)
1,1,2 looks the same as 1,1,3.
all x,y,z1 looks the same as any x,y,z2 for any values of z1 and z2
You could create the illusion that something is coming "out of the page" by drawing higher values of z bigger. It would not change the angle, but it would be a visual hint of the z value.
Lastly, you can use Dinal24's method. You would apply the same technique twice, once for x/y, and then again with the z.
This page may be helpful: http://www.mathopenref.com/trigprobslantangle.html
Rather than code this up yourself, try to find a library that already does it, like https://processing.org/reference/PVector.html
In my experiment, i conclude these:
YourView.transform = CGAffineTransformMakeRotation( positive value );
will rotate the view clockwise, and
YourView.transform = CGAffineTransformMakeRotation( Negative value );
will rotate the view counterclockwise,
But the document says:
The angle, in radians, by which to rotate the affine transform. In iOS, a positive value specifies counterclockwise rotation and a negative value specifies clockwise rotation.
does those contradict with each other?
Your confusion is quite understandable.
In truth, a positive angle represents a rotation from the positive X axis toward the positive Y axis. A negative angle represents a rotation from the positive X axis toward the negative Y axis.
The “native” Core Graphics coordinate system is modeled after the standard Cartesian coordinate system, in which the Y axis increases upward on the page. In this system, a positive angle represents a counter-clockwise rotation:
So if you create your own CGContext (for example, by using CGBitmapContextCreate or CGPDFContextCreate), rotations will work as you expect.
However, computer systems have historically used a coordinate system in which the Y axis increases downward on the page. In a flipped coordinate system like this, a positive angle represents a clockwise rotation:
Notice that in both coordinate systems, a positive angle rotates from the positive X axis toward the positive Y axis.
It turns out that UIKit flips the coordinate system of the graphics contexts that it creates for you. This includes the graphics context it sets up before sending you drawRect: and the graphics context it sets up in UIGraphicsBeginImageContext. (The Quartz 2D Programming Guide explains this.) You can check this by looking at the current transform matrix (using CGContextGetCTM). You will find that it has a -1 in its d element, meaning that the Y axis is flipped.
A UIView also uses a flipped coordinate system for laying out its subviews, which affects the meaning of the UIView transform property.