I was trying to find a way to calibrate a magnetometer attached to a vehicle as Figure 8 method of calibration is not really posible on vehicle.
Also removing magnetomer calibrating and fixing won't give exact results as fixing it back to vehicle introduces more hard iron distortion as it was calibrated without the vehicle environment.
My device also has a accelerometer and gps. Can I use accelerometer or gps data (this are calibrated) to automatically calibrate the magnetometer
Given that you are not happy with the results of off-vehicle calibration, I doubt that accelerometer and GPS data will help you a lot unless measured many times to average the noise (although technically it really depends on the precision of the sensors, so if you have 0.001% accelerometer you might get a very good data out of it and compensate inaccuracy of the GPS data).
From the question, I assume you want just a 2D data and you'll be using the Earth's magnetic field as a source (as otherwise, GPS wouldn't help). You might be better off renting a vehicle rotation stand for a day - it will have a steady well known angular velocity and you can record the magnetometer data for a long period of time (say for an hour, over 500 rotations or so) and then process it by averaging out any noise. Your vehicle will produce a different magnetic field while the engine is off, idle and running, so you might want to do three different experiments (or more, to deduce the engine RPM effect to the magnetic field it produces). Also, if the magnetometer is located close to the passengers, you will have additional influences from them and their devices. If rotation stand is not available (or not affordable), you can make a calibration experiment with the GPS (to use the accelerometers or not, will depend on their precision) as following:
find a large flat empty paved surface with no underground magnetic sources (walk around with your magnetometer to check) then put the
vehicle into a turn on this surface and fix the steering wheel use the cruise control to fix the speed
wait for couple of circles to ensure they are equal make a recording of 100 circles (or 500 to get better precision)
and then average the GPS noise out
You can do this on a different speed to get the engine magnetic field influence from it's RPM
I had performed a similar procedure to calibrate the optical sensor on the steering wheel to build the model of vehicle angular rotation from the steering wheel angle and current speed and that does not produce very accurate results due to the tire slipping differently on a different surface, but it should work okay for your problem.
We have an embedded device mounted in a vehicle. It has accelerometer, gyrosopce and GPS sensors on board. The goal is to distinguish when vehicle is moving forward and backward (in reverse gear). Sensor's axis are aligned with vehicle's axis.
Here's our observations:
It's not enough to check direction of acceleration, because going backwards and braking while moving forward would show results in the same direction.
We could say that if GPS speed decreased 70 -> 60 km/h it was a braking event. But it becomes tricky when speed is < 20 km/h. Decrease 20 -> 10 km/h is possible when going both directions.
We can't rely on GPS angle at low speeds.
How could we approach this problem? Any ideas, articles or researches would be helpful.
You are looking for Attitude and heading reference system implementation. Here's an open source code library. It works by fusing the two data sources (IMU and GPS) to determine the location and the heading.
AHRS provides you with roll, pitch and yaw which are the angles around X, Y and Z axises of the IMU device.
There are different algorithms to do that. Examples of AHRS algorithms are Madgwick and Mahony algorithms. They will provide you with quaternion and Eurler angles which can easily help you identify the orientation of the vehicle at any time.
This is a cool video of AHRS algo running in real time.
Similar question is here.
EDIT
Without Mag data, you won't get high accuracy and your drift will increase over time.
Still, you can perform AHRS on 6DoF (Acc XYZ and Gyr XYZ) using Madgwick algorithm. You can find an implementation here. If you want to dive into the theory of things, have a look at Madgwick's internal report.
Kalman Filter could be an option to merge your IMU 6DoF with GPS data which could dramatically reduce the drift over time. But that requires a good understanding of Kalman Filters and probably custom implementation.
I have 2 movable points. When the distance between them exceeds 10 ft, I want to get an alert. Is this possible? What is the minimum distance that is measurable?
Maybe this will help you further.
How accurate is GPS?
It depends. GPS satellites broadcast their signals in space with a certain accuracy, but what you receive depends on additional factors, including satellite geometry, signal blockage, atmospheric conditions, and receiver design features/quality.
For example, GPS-enabled smartphones are typically accurate to within a 4.9 m (16 ft.) radius under open sky (VIEW SOURCE AT ION.ORG). However, their accuracy worsens near buildings, bridges, and trees.
I'm wondering what the minimum working distance for the Kinect is.
I'd like to track a moving object (10cm x 10cm) from a distance of 1m. The area that the object will be moving in, is 120cm x 60cm.
Given Kinect's specs, will it be possible to track the object across the entire area?
wikipedia says:
The sensor has an angular field of view of 57° horizontally and 43°
vertically
so the answer to your question would be: no, 120cm would be too wide. Since the maximum horizontal viewing field at 1m would be tan(57deg/2)*2 = ~1.08m
though at a distance of ~1.2m it should work (tan(57deg/2)*2*1.2 = ~1.3m)
Distance range handled by the sensor is 850mm minimum and 4000mm maximum, so this should be possible.
I strongly recommend watching the Kinect SDK Quickstarts videos as it covers all basics to get you started. In fact the "Working with depth data" probably contains exactly the kind of info you're looking for.
How precise is the depth camera in the kinect?
range?
resolution?
noise?
Especially I'd like to know:
Are there any official specs about it from Microsoft?
Are there any scientific papers on the subject?
Investigations from TechBlogs?
Personal experiments that are easy to reproduce?
I'm collecting data for about a day now, but most of the writers don't name their sources and the values seem quite to differ...
Range: ~ 50 cm to 5 m. Can get closer (~ 40 cm) in parts, but can't have the full view be < 50 cm.
Horizontal Resolution: 640 x 480 and 45 degrees vertical FOV and 58 degrees horizontal FOV. Simple geometry shows is about ~ 0.75 mm per pixel x by y at 50 cm, and ~ 3 mm per pixel x by y at 2 m.
Depth resolution: ~ 1.5 mm at 50 cm. About 5 cm at 5 m.
Noise: About +-1 DN at all depths, but DN to depth is non-linear. This means +-1 mm close, and +- 5 cm far.
There are official specs from the sensor developer, not from Microsoft. No scientific papers that I know of yet. Plenty of investigations and experiments (see Google). The OpenKinect has a lot more discussion on these things than this site for now.
The Kinect for Windows SDK provide some constants which I've been using and seem to be consistent. For range and resolution, these values are:
In default mode:
Minimum range: 80 cm
Maximum range: 400 cm
In near mode:
Minimum range: 40 cm
Maximum range: 300 cm
For the color camera, you may have either of the following resolutions:
80x60
320x240
640x480
1280x960
For the depth camera, you may have either of the following resolutions:
80x60
320x240
640x480
Confronting the information from Avada Kedavra (and from most sources, by the way), the values for the field of view given by the API are the following:
For the color camera:
Horizontal FOV: 62,0°
Vertical FOV: 48,6°
For the depth camera:
Horizontal FOV: 58,5°
Vertical FOV: 45,6°
Source: http://msdn.microsoft.com/en-us/library/hh855368
The real question here was about resolution and precision. I care to chip in here as i find the resolution and precision to be not as good as stated. The maximum output of the depth resolution is indeed 640x480, however, this is not the effective resolution, and this is not exactly how precise it is.
The method in which the kinect works is based on structured light projection. A pattern of light is emitted and cast on the surface, which a camera sees and then triangulates each ray from the origin, bounced off the object, to the camera.
The thing is that this pattern consists out of only 34.749 bright spots that can be triangulated (http://azttm.wordpress.com/2011/04/03/kinect-pattern-uncovered/). If we relate this to a resolution of 640x480=307.200 data points, we notice a great difference. Ask yourself if the amount of data 10 times the amount of source-data-points can be seen as valid, and sampled efficiently. I doubt it. If you were to ask me what the effective resolution of the kinect is, i would guess it is around 240x180 of honest and pretty good data.
According to Kinect tech spec finally revealed the specs for the depth field are (these match is also confirmed in the official programming guide as posted by Mannimarco):
* Horizontal field of view: 57 degrees
* Vertical field of view: 43 degrees
* Physical tilt range: ± 27 degrees
* Depth sensor range: 1.2m - 3.5m
* Resolution depth stream: 320x240 pixels
* Resolution color stream: 640x480 pixels
But from my own experience the depth sensor range is more like 0.8m-4.0m, at least I get good reading in this range. This range matches the Primesense data sheet posted by mankoff in the comments below.
It is also important to remember that the depth resolution is much higher close to the sensor than further away. At 3-4 meter the resolution is not nearly as good as at 1.5m. This becomes important if you, for example, want to calculate the normals of the surface. The result will be better closer to the sensor than further away.
Its not to hard to test the range yourself. The Official SDK (currently beta) will give you a a zero (0) depth when you are out of range. So, you could test this with a simple ruler, and test at what distance you get/dont get any reading larger than zero. I do not know how the OpenKinect SDK handles out-of-range readings.
A comment about noise: I would say that there is quite a bit of noise in the depth stream which makes it harder to work with. For example if you calculate the surface normals you can expect them to be a bit "jumpy" which of course will have a negative impact on fake lighting etc. Furthermore you have a parallax issue in the depth stream due to the distance between the IR transmitter and the receiver. This can also be hard to work with as it leave a large "shadow" in the depth data. This youtube video demonstrates the problem and discuss a way to resolve the issue using shaders. Its a video worth watching.
I think it might be worth mentioning the paper of Khoshelham and Elbernik who did propose a theoretical random error model of the kinects depth sensor in Feb '12. It is called "Accuracy and Resolution of Kinect Depth Data for Indoor Mapping Applications".
The paper can be found here.
If you're looking for something published by Microsoft, check out page 11 of the Kinect Programming Guide. It says pretty much the same thing everyone here has already mentioned.
Range: 1.2 to 3.5 meters
Viewing angle: 43° vertical by 57° horizontal
Mechanized tilt range: ±28°
Frame rate: 30 frames per second
Resolution, depth stream: 320 x 240 (it can actually go higher than this)
Resolution, color stream: 640 x 480 (again, it can go higher)
I don't see anything mentioning noise, but I can say it's pretty minimal except along surface edges where it can become more noticeable.
My experience is that it is not that exact. It's pretty OK, but when you compare it to tape measure, then it is not exactly matching. I made an Excel with measurements for every 10mm, and it just doesn't hold up, especially things that are more then 2500mm away, but more closer too.
Keep also in mind that the actual depth pixels is a lot lower then is advertised. The electronics inside fills in the gasps, that's why you see small area artifacts, and not something like pixel data. In essence this means that 320x240 has 1/8 pixels covered by a "real" measurement, other pixels are calculated. So you could use 640x480; but it would only CPU/UBS resource and will not make your application see better.
That's just my two cents of experience, I'm programming robotics.