I'm working with a Kinect 1414 with the library kinect4WinSDK (processing).
First, I have my depth value as a raw value between 6400 and 30 000. I convert it with this:
if (raw==0x0000) z=0.0;
else if (p.raw>=0x8000) p.z=4.0;
else p.z=0.8+(float(p.raw-6576)*0.00012115165336374002280501710376283);
However, my x and y value are in a range [0,1] for x and [-1,1] for y. I wanted these value in meter. Can you help me?
Thanks,
Yoann
The thing is you need to get the corresponding real world 1 meter in computer space(Kinect space). The kinect itself is not measuring respect to any standard unit. So you need to map a real world 1 meter to Kinect distance. For this get a 4 meter distance and mark it with kinect skeleton hand for both ends and get the distance in the computer space and let's say it is x. Now if you get a d distance in real world then the corresponding Kinect space distance is (x/4c)*d. C can be calculated.
Related
The following image is the example that was given in my computer vision class. Now I cant understand why we are getting 2 unique values of f. I can understand if mxf and myf are different, but shouldn't the focal length 'f' be the same?
I believe you have an Fx and a Fy. This is so that the the matrix transforms on f can scale f in two directions x and y. IIRC this is why you get 2 f numbers
If really single f wanted, it should be modeled in the camera model used in calibration.
e.g. give the mx,my as constants to the camera model, and estimate the f.
However, perhaps the calibration process that obtained that K was not that way, but treated the two elements (K(0,0) and K(1,1)) independently.
In other words, mx and my were also estimated in the sense of dealing with the aspect ratio.
The estimation result is not the same as the values of mx and my calculated from the sensor specifications.
This is why you got 2 values.
The Kinect creates a depthmap by measuring the 3D euclidean distance between a point and the sensor position for every pixel. This depthmap can then be reprojected into 3D camera space, for example as described in http://nicolas.burrus.name/index.php/Research/KinectCalibration
In particular, the z coordinate of the projected point is set to the measured depth of that pixel, which seems wrong to me, because it implies that the depth is measured as orthogonal distance to the sensor plane, not as 3D euclidean distance to the sensor position.
So which one is correct? Distance to sensor plane or distance to sensor position?
The measured depth is calculated as orthogonal distance, as described by 1 and given by the figure below:
Another similar answer can be seen here..
1: M. Andersen, T. Jensen, P. Lisouski, A. Mortensen, M. Hansen, T. Gregersen, and P. Ahrendt, “Kinect Depth Sensor Evaluation for Computer Vision Applications,” Technical Report Electronics and Computer Engineering, vol. 1, no. 6, 2015.
Currently I'm trying the following: I have points from google earth (WGS84) which I want to transform to a local x,y coordinate system: a tangential plane with y positive from south to north and x positive from west to east.
There is no need for the plane to be part of a global coordinate system more than the relation (x=0, y=0) = (lat,lon). The scale at which I'm working is in the order of say 100 kilometers (maximum of for example 200 km's). Very small errors (due to for example the curvature of the earth) are acceptable.
I have relatively little understanding of this topic as of yet. Can anybody help me out? Where would I need to look for example.
Thanks!
I haven't found the answer mathematically but have found that the package basemap (of the mpl_toolkit) should help with this respect (from wgs84 to a transverse mercator projection).
I have a set of GPS Coordinates and I want to find the speed required for a UAV to travel between them. Doing this by calculating distance in x y z and then dividing by time to travel - m/s.
I know the great circle distance but I assume this will be incorrect since they are all relatively close together(within 10m)?
Is there an accurate way to do this?
For small distances you can use the haversine formula without a relevant loss of accuracy in comparison to Vincenty's f.e. Plus, it's designed to be accurate for very small distances. This can be read up here if you are interested.
You can do this by converting lat/long/alt into XYZ format for both points. Then, figure out the rotation angles to move one of those points (usually, the oldest point) so that it would be at lat=0 long=0 alt=0. Rotate the second position report (the newest point) by the same rotation angles. If you do it all correctly, you will find X equals the east offset, Y equals the north offset, and Z equals the up offset. You can use Pythagorean theorm with X and Y (north and east) offsets to determine the horizontal distance traveled. Normally, you just ignore the altitude differences and work with horizontal data only.
All of this assumes you are using accurate formulas to convert lat/lon/alt into XYZ. It also assumes you have enough precision in the lat/lon/alt values to be accurate. Approximations are not good if you want good results. Normally, you need about 6 decimal digits of precision in lat/lon values to compute positions down to the meter level of accuracy.
Keep in mind that this method doesn't work very well if you haven't moved far (greater than about 10 or 20 meters, more is better). There is enough noise in the GPS position reports that you are going to get jumpy velocity values that you will need to further filter to get good accuracy. The math approach isn't the problem here, it's the inherent noise in the GPS position reports. When you have good reports, you will get good velocity.
A GPS receiver doesn't normally use this approach to know velocity. It looks at the way doppler values change for each satellite and factor in current position to know what the velocity is. This works reasonably well when the vehicle is moving. It is a much faster way to detect changes in velocity (for instance, to release a position clamp). The normal user doesn't have access to the internal doppler values and the math gets very complicated, so it's not something you can do.
I am currently trying to figure out a way to calcute the size of a given object with kinect
since I have the following data
angular field of view of the lens
distance
and width in pixels from a 800*600 resolution
I believe this can be possible to calculate. Does anyone has math skills to give me a little help?
With some trigonometry, it should be possible to approximate.
If you draw a right trangle ABC, with the camera at one of the legs (A), and the object at the far end (edge BC), where the right angle is (C), then the height of the object is going to be the height of leg BC. the distance to the pixel might be the distance of leg AC or AB. The Kinect sensor specifications are going to regulate that. If you get distance to the center of a pixel, then it will be AC. if you have distances to pixel corners then the distance will be AB.
With A representing the angle at the camera that the pixel takes up, d is the distance of the hypotenuse of a right angle and y is the distance of the far leg (edge BC):
sin(A) = y / d
y = d sin(A)
y is the length of the pixel projected into the object plane. You calculate it by multiplying the sin of the angel by the distance to the object.
Here I confess I do not know the API of the kinect, and what level of detail it provides. You say you have the angle of the field of vision. You might assume each pixel of your 800x600 pixel grid takes up an equal angle of your camera's field of vision. If you do, then you can break up that field of vision into equal pieces to measure the linear size of your object in each pixel.
You also mentioned that you have the distance to the object. I was assuming that you have a distance map for each pixel of the 800x600 grid. If this is incorrect, some calculations can be done to approximate a distance grid for the pixels involving the object of interest if you make some assumptions about the object being measured.