I am implementing a software that reads the raw data by an accelerometer (connected via USB port) and rotates a virtual object (for example a cube in unity3d environment).
From the raw data given by the accelerometer I calculate the accelerator components:
Xg = raw_data[0]*range/pow(2,resolution-1) //for x accelerator component
Yg = raw_data[1]*range/pow(2,resolution-1) //for y accelerator component
Zg = raw_data[2]*range/pow(2,resolution-1) //for z accelerator component
where range and resolution are provided by accelerometer datasheet.
Then I calculate the pitch and roll angles by means these formulas:
roll = arctg(-Xg/Zg)*180/PI
pitch = arctg(Yg/sqrt(pow(Xg,2)+pow(Zg,2)))-180/PI
Finally I get the yaw angle from gyroscope.
In order to rotate an object in my scene I set its euler angles to these value but the object has a full rotation in x and z axis (roll angle and yaw angle), but not in y axis (pitch angle) where the object rotates only 180 degrees.
The problem is that the pitch angle is in range [-90,90] degrees and the object
cannot have a 360degrees rotation.
Is there a formula for pitch angle to have a 360 degrees rotation also for the y axis? Thanks a lot.
Related
I am currently working on block-breaking in a Minecraft clone. In order to do so, I want use the camera's Euler angles to determine the direction vector of the camera's ray.
I have 2 angles: pitch and yaw.
Pitch rotates along the X axis and is positive when the player looks down, and negative when the player looks up. It cannot be greater than 90 degrees (looking straight down) and cannot be smaller than -90 degrees (looking straight up)
Yaw rotates along the Y axis. It can be a negative number and a positive number, depending on how many times the player turned and in which direction. For example, the player spawns in (yaw = 0) and instantly spins counter-clockwise 360 degrees. In such a case, yaw = -360.
As stated in the question, I am using OpenGL, so when yaw = 0, the player is looking down the negative Z-axis.
How can I generate a direction vector (must be a unit-vector) using only the Euler angles with the restrictions described above?
From your description of Pitch and Yaw, I am assuming that you are using a left-hand reference (pitch=0 and yaw=0 gives a camera vector (0.0, 0.0, 1.0).
The Pitch parameter moves the camera vector in the YZ plane :
Y = cos(pitchInRadians)
Z = sin(pitchInRadians)
The Yaw parameter moves the camera vector in the XZ plane :
X = sin(yawInRadians)
Z = cos(yawInRadians)
Combining the two would give you your final camera vector :
Cv = (sin(yaw), cos(pitch), sin(pitch)*cos(yaw))
As you should have noted, the angles are in radians. Since your post mentions angles in degrees, you will have to convert your degree angles to radians first :
radians = (degrees * PI) /180
Im working now with some mod for the game, exactly i need rotate my player to any object.
I have two vector3, its my pos and object pos.
As usually we can
Vector3 Dir = object - mypos to get direction and calculate yaw and pitch using atan2 function, write it to our player angle and we will done rotation.
Problem. I first time see pitch value between 180 (mouse up) and 360 (mouse down), yaw 0 - 360, roll 0 (doesn’t matter now). Its represents as Vector3 euler. Of course if im using atan2 way i getting incorrect values for this eluer vector cause i getting less small (Lower than 180) or negative values for pitch, yaw seems in range. How to calculate correct?
My calcs:
Vector3 DoorDir = DoorOrigin - PlayerOrigin;
DoorDir = NormalizeVec(DoorDir);
float yaw = Rad2Deg(atan2(DoorDir.x, DoorDir.z));//Game has XZY coords.
float pitch = Rad2Deg(-1.f * atan2(DoorDir.y, sqrtf(DoorDir.x * DoorDir.x + DoorDir.z * DoorDir.z)));
SetAngles(Vector2(yaw,pitch)//Sets angles (converted yaw and pitch back to DEG)
I am trying to make an image move towards my mouse pointer. Basically, I get the angle between the points, and move along the x axis by the cosine of the angle, and move along the y axis the sine of the angle.
However, I don't have a good way of calculating the angle. I get the difference in x and the difference in y, and use arctangent of Δy/Δx. The resulting angle in quadrant 1 is correct, but the other three quadrants are wrong. Quadrant 2 ranges from -1 to -90 degrees. Quadrant 3 is always equal to quadrant 1, and quadrant 4 always equals quadrant 4. Is there an equation that I can use to find the angle between the two points from 1-360 degrees?
Note: I cannot use atan2(), and I do not know what a vector is.
// This working code is for Windows HDC mouse coordinates gives the angle back that is used in Windows. It assumes point 1 is your origin point
// Tested and working on Visual Studio 2017 using two mouse coordinates in HDC.
//
// Code to call our function.
float angler = get_angle_2points(Point1X, Point1Y, Point2X, Point2Y);
// Takes two window coordinates (points), turns them into vectors using the origin and calculates the angle around the x-axis between them.
// This function can be used for any HDC window. I.e., two mouse points.
float get_angle_2points(int p1x, int p1y, int p2x,int p2y)
{
// Make point1 the origin, and make point2 relative to the origin so we do point1 - point1, and point2-point1,
// Since we don’t need point1 for the equation to work, the equation works correctly with the origin 0,0.
int deltaY = p2y - p1y;
int deltaX = p2x - p1x; // Vector 2 is now relative to origin, the angle is the same, we have just transformed it to use the origin.
float angleInDegrees = atan2(deltaY, deltaX) * 180 / 3.141;
angleInDegrees *= -1; // Y axis is inverted in computer windows, Y goes down, so invert the angle.
//Angle returned as:
// 90
// 135 45
//
// 180 Origin 0
//
//
// -135 -45
//
// -90
// The returned angle can now be used in the C++ window function used in text angle alignment. I.e., plf->lfEscapement = angle*10;
return angleInDegrees;
}
The answers regarding atan2 are correct. For reference, here is atan2 in Scratch block form:
If you're unable to use atan2() directly, you could implement its internal calculations on your own:
atan2(y,x) = atan(y/x) if x>0
atan(y/x) + π if x<0 and y>0
atan(y/x) - π if x<0 and y<0
This is the code I use, and it seems to work perfectly fine.
atan(x/y) + (180*(y<0))
where X is the difference between the Xs of the points (x2 - x1), and Y is the difference between the Ys (y2 - y1).
atan((x2-x1)/(y1-y2)) + (180*((y1-y2)<0))
To control a robotic arm, I have a controller with 6 dimensions (x, y, z position, and roll, pitch, yaw rotation). I am using a position (x, y, z) and quaternion (x, y, z, w) to represent the desired position and orientation of the robot's gripper.
I am using some libraries that people might not be familiar with (namely, geometry_msgs from ROS), so here is what I'm doing in pseudocode:
while(true):
new_position = last_position + (joy.x, joy.y, joy.z)
new_quaternion = last_quaternion * quaternionFromRPY(joy.roll, joy.pitch, joy.yaw)
// (Compute inverse kinematics using position and orientation, then send to robot arm)
last_position = new_position
last_quaternion = new_quaternion
delay(dt)
I am able to set the x, y, and z of the position part of the pose just fine. Technically, I am also able to set the quaternion just fine as well, but my problem is that controlling the quaternion is extremely non-intuitive, since rotation is not commutative. i.e., if I rotate 180 degrees about the x-axis, then the control of the rotation about the z-axis gets inverted.
Is there any way that I can control the rotation from a sort of "global reference frame," if that makes any sense? I would like it so that if I twist the joystick clockwise about z, the pose will rotate accordingly, instead of "sometimes rotating clockwise, sometimes rotating counterclockwise."
Isn't this just as simple as exchanging the order of the factors in the quaternion product?
A unit quaternion q transforms a vector v in local coordinates to the rotated vector q*v*q' in global coordinates. A modified quaternion a*q*b (a, b also unit quaternions) transforms v as
a*(q*(b*v*b')*q')*a',
where the b part can be interpreted as rotation in local coordinates and the a part as rotation in global coordinates.
So to apply a rotation in global coordinates only, set b=1, i.e., leave it out, and put the desired rotation in the a factor.
How can I efficiently limit camera pitch when I have only camera quaternion? Do I have to convert to euler angles and then back to quaternion or is there any other way?
If the camera never has any roll (as is common in lots of games, such as first person shooters), then the solution is simple. If there is roll, then there's an additional step involved. I'll start with what to do if there is no roll, and generalize the solution to what to do if there is.
Let qc be the camera rotation. Let qy a rotation with the same yaw as qc, but with zero pitch. If there is no roll, the camera rotation is a yaw rotation followed by a pitch rotation:
qc = qp * qy
We can recover the pitch rotation qp as the rotation from qy to qc:
qp = qc * qy^-1
The trick, then, is to construct qy, so we can plug it into the above equation to solve for qp. Let vc be the unit vector pointing out of the lens of the camera, or the "forward vector". Let vy be the same vector, but projected to the horizontal plane and normalized. Finally, let v0 be the forward vector when the camera rotation qc is the identity rotation. The rotation that rotates v0 into vy is the yaw rotation. The angle can be given as:
yaw = asin(Norm(cross(v0, vy)))
The corresponding yaw rotation is:
qy = { cos(yaw/2), up * sin(yaw/2) }
Where "up" is the unit vector in the up direction, aka the axis for yaw rotations. Plug this into qp = qy^-1 * qc above to get pitch quaternion qp. Finally, get the pitch angle from qp as:
pitch = 2*asin(Dot(right, [qp[1], qp[2], qp[3]]))
Where "right" is the unit vector in the right direction, aka the axis for pitch rotations.
Like I said, things get more complicated if the camera also has roll, but the general strategy is the same. You formulate the camera rotation as a product of rotation components, then isolate the component you want (in this case, pitch). For example, if the euler sequence you use to define "pitch" is the common yaw-pitch-roll sequence, you define qc as:
qc = qr * qp * qy
We can define a variable qx to be the combined pitch and roll rotations:
qx = qr * qp
We can now write qc as:
qc = qx * qy
We already know how to solve for qx in this form, by retracing the steps we used above to solve for qp. Rearranging the definition for qx, we get:
qp = qr^-1 * qx
We just solved for qx, so to solve for the pitch rotation qp, we only need the roll qr. We can construct it using vectors as we did previously. Let vc be the forward vector again. The roll will be a rotation around this vector. Let vu be the camera's up vector (in world coordinates), and let vu0 be the camera's up vector with zero roll. We can construct vu0 by projecting the global up vector to the plane perpendicular to vc, then normalizing. The roll rotation qr is then the rotation from vu0 to vu. The axis of this rotation is the forward vector vc. The roll angle is
roll = asin(Dot(vc, cross(vu0, vu)))
The corresponding quaternion is:
qr = { cos(roll/2), forward * sin(roll/2) }
Where "forward" is the axis of roll rotations.
The pitch is just one component of the full rotation, so if you want to think about your rotation like that, you'd better store the pitch separately, possibly using Euler angles.
Just converting to Euler angles and back when you need to limit the movement might not work too well, since you'l need to remember the last frame (if you have any) to see if you passed the limit, and in what direction.
As I see it, the main point of quaternions is that you don't need to bother with limits like that. Everything just works without any singularities. Why exactly do you want to limit the pitch?
Camera rotation quaternions can be defined as:
vector A = [x, y, z]
Q.x = A.x * sin(theta/2)
Q.y = A.y * sin(theta/2)
Q.z = A.z * sin(theta/2)
Q.w = cos(theta/2)
Where A is the position and theta is the angle you want to rotate the camera (adjust the pitch).
So if you have the quaternion available you can limit the angle of pitch by verifying each time if the rotation angle plus/minus the actual angle is ok.
I think you can avoid conversion if you set your limits as
+cos(supLim/2) < (Q.w + P.w) < -cos(infLim/2)
As cosine is an continuous function this is supposed to work.
If you could post the code you're actually using maybe we can help a little more.
I may be a little late to the party, but this is how I solved it:
// "Up" = local vector -> rotation * Vector3.UnitY
// "Forward" = local vector -> rotation * Vector3.UnitZ
// "Right" = local vector -> rotation * Vector3.UnitX
public void Rotate(Vector3 axis, float angle)
{
if (LerpRotation)
{
RotationTarget *= Quaternion.FromAxisAngle(axis, angle);
}
else
{
Rotation *= Quaternion.FromAxisAngle(axis, angle);
}
//Locking the Pitch in 180°
float a = Vector3.CalculateAngle(Vector3.UnitY, Up);
float sign = Math.Sign(Forward.Y);
float delta = (float)Math.PI / 2 - a;
if(delta < 0)
Rotation *= Quaternion.FromAxisAngle(Right, delta * sign);
}