I would like to help me in this problem.
I am working on three wheels omni robot project , I am using arduino as a brain with ROS (Robot Operating System), but I am facing a problem in the kinematics of the robot,when I am trying to control the robot via twist teleop it works well for all the keys except I and < (these keys must stop the second motor but the motor stills moving).
Below is the part code that returns to the kinematics I used.
Any help would be greatly appreciated.
void omni_drive(double x, double y, double theta) {
float vc = -0.5 * vx - sqrt(3)/2 * vy+theta;
float vb = -0.5 * vx + sqrt(3)/2 * vy+theta;
float va = vx+theta;
}
Related
While reading Physically Based Rendering in Filament I found a few interesting paragraphs in section 4.4.1 about optimizing the implementation of a GGX NDF approximation for half precision floats. I understood that the calculation of 1 - dot(n, h) * dot(n,h) can cause so called catastrophic cancellation and why using the cross product solves the problem, however I didn't get how is any of this related to half precision floats.
It seems that GLSL does not have any half specifier, unlike HLSL (which simply maps it to float since D3D10 most likely because modern desktop hardware doesn't support it anyway; though it seems that with the newest hardware its back again). The thing with Filament is that it is primarly developed for mobile platforms like Android, where half precision floats are supported in hardware.
I understand that using half precision floats is important for performance on both mobile and the most modern desktop targets. As such I would like to understand how is the following code optimized for half precision floats as I can see no half specifier or similar, but merely some constant and a macro:
#define MEDIUMP_FLT_MAX 65504.0
#define saturateMediump(x) min(x, MEDIUMP_FLT_MAX)
float D_GGX(float roughness, float NoH, const vec3 n, const vec3 h) {
vec3 NxH = cross(n, h);
float a = NoH * roughness;
float k = roughness / (dot(NxH, NxH) + a * a);
float d = k * k * (1.0 / PI);
return saturateMediump(d);
}
For completeness, here is the unoptimized code:
float D_GGX(float NoH, float roughness) {
float a = NoH * roughness;
float k = roughness / (1.0 - NoH * NoH + a * a);
return k * k * (1.0 / PI);
}
While GLSL does not have a half type, it does have precision qualifiers whose effects are exclusive-to and dependent-on mobile platforms. I'm assuming that the (complete) optimized shader code from your example contains a default qualifier setting floats to mediump like so:
precision mediump float; Note though that the actual precision remains unspecified, a mediump float might have 16 bits on one platform while it has 24 bits on another.
Here's the catch though: As stated in the linked article and the GLSL specification precision qualifiers are only supported for portability and ought to have no effect on desktop platforms. That means that even desktop GPUs with float16 support would break with the specification if they honored the precision qualifier. On desktop platforms you'll have to enable and use the appropriate extension(e.g. GL_AMD_gpu_shader_half_float) and its specific syntax(e.g. types) to utilize the float16 capabilities.
Recently I started a project where I need to calculate the distance between two points given their latitude and longitude and select and order the points by distance.
The logical step to do this is to use the Haversine formula:
Distance = 2 * R * ASIN( SQRT( SIN( (RADIANS(lat1)-RADIANS(lat2))/2 )^2 + COS( RADIANS(lat1) )*COS( RADIANS(lat2) )*SIN( (RADIANS(long1)-RADIANS(long2))/2 )^2 ) )
This is not a problem for MySQL DB, but for some reasons I needed to use SQLITE database and I was building my project with Laravel.
The problem with SQLITE is that has few math functions, and none trigonometric functions (sin, cos, etc.)
At first I thought of using SQLITE extensions, but it seems that PDO that is used by Laravel for DB connections does not allow to load them.
Then I tried PHP createFunction to define functions in SQLite, but, as far as I understand it only works with scalars, that means it does not accept fields names as argument of the defined functions.
I was stucked.
I needed to work with small distances (less than 20km) and I did not need high precision. So a plane geometry was enough for me, but how?
At last, I remembered that sin(angle) ~ angle if angle is small. So I went through the Haversine formula trying to simplify it. It seems a spherical solution of the Pythagorean theorem.
It is done by two parts, the first one defines the difference in latitude, let's say the Y.
Y = R * ABS(RADIANS(lat1)-RADIANS(lat2))
The second part defines the difference in longitude, let's say the X.
X = R * COS(RADIANS(lat0)) * ABS(RADIANS(long1)-RADIANS(long2))
In this part there is a COS since the radius of the circle changes with the latitude. It could be a problem since I said that SQLite does not have that function, but since we are using small variations of the angles lat0 can be a constant value, and calculated once for ever.
Since I have one point given by the user I can put lat0 = lat1 and calculate COS(lat1) before the query or you can define it for your location.
The last thing is to calculate the Estimated_Distance^2 = X^2 + Y^2. Well, SQLite does not even have the SQRT functions, so you must keep it elevated by 2...
The final formula is:
Estimated_Distance = SQRT ( ( R * ABS(RADIANS(lat1)-RADIANS(lat2)) ) ^ 2 + ( R * COS(RADIANS(lat0)) * ABS(RADIANS(long1)-RADIANS(long2)) ) ^ 2 )
The result is not too bad, the error against the Haversine formula is less than 1 m when the distance is less than 10-15 km, but it grows fast with higher distances.
When I will move the project on a production server I'll use MySQL and the correct formula, in the meanwhile this is good enough for me.
If you have any suggestion to improve it, please let me know.
I hope this can help.
I wonder how lenghtdir_x/y is implemented. To my understanding this has something to do with trigonometry but since I'm a fairly new to all of this I can't figure it out myself.
You are correct, it is a bit of trigonometry - namely, converting from degrees to radians, and then multiplying a sine/cosine of that angle by "length" (hence why it is called length-dir)
lengthdir_x(l, d) is l * cos(d * pi / -180)
lengthdir_y(l, d) is l * sin(d * pi / -180)
live demo for comparison
I'm looking for some math, nothing language dependant.
"Standard" gravity for an object in a game would go something like this:
if player.y > ground.y {
player.velocity.y = player.velocity.y - gravity
}
In the little simulation I'm implementing I would actually like the gravity to weaken, and the velocity to slow, as the player approaches the ground.
IE: When the object is 100m above ground it should fall faster than when it's 1m above ground. It should land like a feather in a way.
I imagine the gravity needs to be some kind of function of the distance between the object and the ground.
I've been searching around Google but as I've not done math in a while and I don't know the name of what I'm looking for, I've not had much luck.
(Note: I considered posting on the SE: Game Dev but as it's more about math/programming than game design itself I though it would be more appropriate here)
You're correct in your assumption that gravity needs to be a function. The following snippet (source: http://gafferongames.com/game-physics/integration-basics/) applies more gravity for higher values of x, where State is a struct for position and velocity in a single dimension.
float acceleration( const State &state )
{
const float k = 10;
const float b = 1;
return -k * state.x - b*state.v;
}
You want the reverse of this, which you can achieve by changing the value of b based on distance to the ground, or applying negative acceleration after some threshold.
Im working on a Quadrotor project and i want to read data from my imu. i tried mpu6050 library but got just accelerometer and gyro data. i don't know how to access magnetometer data and use all these information to calculate pitch roll and yaw. the sensor Im using is GY9250. Im new in this field and i don't know mathematics.
ill be glad if someone can help me. thank you...
this is what i did:
accelgyro.getAcceleration(&ax, &ay, &az);
//Low Pass Filter
fXa = ax * alpha + (fXa * (1.0 - alpha));
fYa = ay * alpha + (fYa * (1.0 - alpha));
fZa = az * alpha + (fZa * (1.0 - alpha));
accelgyro.getRotation(&gx, &gy, &gz);
//pitch and roll
roll = (atan2(-fYa, fZa)*180.0)/M_PI;
pitch = (atan2(-fXa, fZa)*180.0)/M_PI;
If you look at the image below you can see that MPU has Digital Motion Processor.
The embedded Digital Motion Processor (DMP) is located within the MPU-60X0 and offloads computation of motion processing algorithms from the host processor.
The DMP acquires data from accelerometers, gyroscopes, and additional 3rd party sensors such as magnetometers, and processes the data. The resulting data can be read from the DMP’s registers, or can be buffered in a FIFO.
The DMP has access to one of the MPU’s external pins, which can be used for generating interrupts.
Then I would suggest you to read this article: http://playground.arduino.cc/Main/MPU-6050
And of course read this one too: http://www.varesano.net/projects/hardware/FreeIMU