I have a Raspberry Pi connected to a monitor and a camera tracking the user. I would like to know the distance of the user to the screen (or to the camera if that is better). Preferably I would like to know the distance from the users face straight to the screen.
Can I do this with just one camera and OpenCV? What about with two cameras?
Otherwise, should I just use a different sensor like the ultrasonic sensor? Is this sensor appropriate if it's below or on the side of the screen? What type of spread/'field of view' does it have?
You could do this with two cameras, I think, by comparing how far the images are displaced, and using some trigonometry. The math will be non-trivial, however. This sounds like a good application for an ultrasonic sensor. The popular HC-SR04 gives pretty accurate (for my purposes) readings from about 30cm to 2m, provided the object is on-axis. I get some useful measurements for objects up to about 20 degrees off axis, but it's considerably less accurate. You can connect a HC-SR04 to the GPIO pins, but I prefer to use commercial i2c interfaces, because doing the timing in the Pi CPU is a pain. In any event, the HC-SR04 is so cheap that you haven't lost a great deal if you buy one just to experiment with.
Related
I would like to construct a platform for my robot that can rotate in 360 degrees.
I have stepper motor that is able to rotate so.
The problem is I have some sensors and controllers placed on that platform so I need to power them up and read data from them.
I need to have wires going from the lower unrotatible level of the robot to that platform.
Picture:
Any thoughts on how could I achieve something like this?
For your application, you will need something to transmit the electrical signals and power to your rotating platform. Thankfully, there is a device called a slip ring which will do just this.
From Wikipedia:
A slip ring is an electromechanical device that allows the transmission of power and electrical signals from a stationary to a rotating structure. A slip ring can be used in any electromechanical system that requires rotation while transmitting power or signals. It can improve mechanical performance, simplify system operation and eliminate damage-prone wires dangling from movable joints.
You can find them from your favorite electronics vendor, but here is an example from Adafruit, distributed by Digikey.
Can you, please, suggest me ways of determining the distance between camera and a pixel in an image (in real world units, that is cm/m/..).
The information I have is: camera horizontal (120 degrees) and vertical (90 degrees) field of view, camera angle (-5 degrees) and the height at which the camera is placed (30 cm).
I'm not sure if this is everything I need. Please tell me what information should I have about the camera and how can I calculate the distance between camera and one pixel?
May be it isn't right to tell 'distance between camera and pixel ', but I guess it is clear what I mean. Please write in the comments if something isn't clear.
Thank you in advance!
What I think you mean is, "how can I calculate the depth at every pixel with a single camera?" Without adding some special hardware this is not feasible, as Rotem mentioned in the comments. There are exceptions, and though I expect you may be limited in time or budget, I'll list a few.
If you want to find depths so that your toy car can avoid collisions, then you needn't assume that depth measurement is required. Google "optical flow collision avoidance" and see if that meets your needs.
If instead you want to measure depth as part of some Simultaneous Mapping and Localization (SLAM) scheme, then that's a different problem to solve. Though difficult to implement, and perhaps not remotely feasible for a toy car project, there are a few ways to measure distance using a single camera:
Project patterns of light, preferably with one or more laser lines or laser spots, and determine depth based on how the dots diverge or converge. The Kinect version 1 operates on this principle of "structured light," though the implementation is much too complicated to reproduce completely. For a collision warning simple you can apply the same principles, only more simply. For example, if the projected light pattern on the right side of the image changes quickly, turn left! Learning how to estimate distance using structured light is a significant project to undertake, but there are plenty of references.
Split the optical path so that one camera sensor can see two different views of the world. I'm not aware of optical splitters for tiny cameras, but they may exist. But even if you find a splitter, the difficult problem of implementing stereovision remains. Stereovision has inherent problems (see below).
Use a different sensor, such as the somewhat iffy but small Intel R200, which will generate depth data. (http://click.intel.com/intel-realsense-developer-kit-r200.html)
Use a time-of-flight camera. These are the types of sensors built into the Kinect version 2 and several gesture-recognition sensors. Several companies have produced or are actively developing tiny time-of-flight sensors. They will generate depth data AND provide full-color images.
Run the car only in controlled environments.
The environment in which your toy car operates is important. If you can limit your toy car's environment to a tightly controlled one, you can limit the need to write complicated algorithms. As is true with many imaging problems, a narrowly defined problem may be straightforward to solve, whereas the general problem may be nearly impossible to solve. If you want your car to run "anywhere" (which likely isn't true), assume the problem is NOT solvable.
Even if you have an off-the-shelf depth sensor that represents the best technology available, you would still run into limitations:
Each type of depth sensing has weaknesses. No depth sensors on the market do well with dark, shiny surfaces. (Some spot sensors do okay with dark, shiny surfaces, but area sensors don't.) Stereo sensors have problems with large, featureless regions, and also require a lot of processing power. And so on.
Once you have a depth image, you still need to run calculations, and short of having a lot of onboard processing power this will be difficult to pull off on a toy car.
If you have to make many compromises to use depth sensing, then you might consider just using a simpler ultrasound sensor to avoid collisions.
Good luck!
So I'm working in this app and got many things done, i can track the ball perfectly on my current videos ( just a small part of the lane currently ). The Idea is to be able to track a bowling ball down the whole lane to calculate all sorts of things ( like speed and position ). My problem is that lanes are 60 foot ( 18m ) long and like 4 ( 1.1m ) wide. I figured the best way to do it was putting the Cameras on the ceiling, because background extraction worked flawlessly so my first test was a USB webcams. My first problems were to discover that ceilings are almost 10 foot ( 3m ) from the floor so i would need a lot of webcams, when i got 1 more i realized 2 things, webcams are not the way because:
a) It doesn't support the bandwidth of streaming the video of many cameras at the time at high res.
b) I would need a lot of webcams because of fixed lens sizes.
c) Unless you use powered cables USB doesn't get very far before losing singal
So i discovered what it seemed to be the solution that is something like 1 or 2 PointGrey cameras (Butterfly or other model) with maybe a 4mm or 8 mm lens would work. At this point my financing is very low and I'm trying to have the least amount of possible errors as is my own startup and as an Argentinean is not as easy to do stuff like being in the US.
My question is what kind of approach would you guys take to be able to capture the whole lane? maybe change camera positions and use other way instead of background extraction? You guys think I'm going on the right track? with the USB cam, at least i was able to capture and follow frame by frame the ball in a very limited space of lane, but i realized i can do everything i want and the project is possible, but USB is not the way.
Hoping to hear some advice as I'm no expert in computer vision or cameras. and i want to do a cost efficient project. I'm currently working on C# using emgu.
Thanks to anyone took the time to read this :)
These approaches came to my mind:
1- I seems that with one camera on the ceiling your system works well but you do not cover the whole lane. Then you can calculate the speed and position in the portion you cover and make an estimation for when the ball goes of the field of view.
2- Another approach is to use a camera with a wider angle on the ceiling.
3- Instead of on the ceiling, you can mount the camera somewhere else (for example on the sides) that covers the whole lane. Since you exactly know the location of your camera you can calculate speed and position based on the location of the ball on the screen (taking into account prespective,etc). The problem with this approach would be that you have to mount the camera always in one point for all customers and the system won't work if camera moved later.
4- The most robust approach to me is stereo vision. You use two cameras with a certain distance to each other, calibrate them. Then you can mount them anywhere that covers the whole lane. Distance, speed, position, etc are all feasible and easy to extract when you have the matrices of two cameras.
put a camera at an angle where it can see the whole lane. For example, you can mount it on a ceiling looking down and forward. Background subtraction should just work fine while the distance can be calibrated based on the initial and final position of the ball. The mapping between the image and the physical world (lane surface) will be given by Homography which requires 4 point correspondences to calculate.
I captured raw magnetometer data on the iPhone 5 by accident, and I actually require the calibrated data. The problem is that I can't go and recapture the data I originally got. Does anyone know what the iPhone's hard bias (device bias) calibration values are and how I can apply them to my data to get a similar output to what the iPhone would have given me?
Alternatively what is the best approach to calibrate for the device bias? I don't care about soft bias in my measurements.
Thanks
The iPhone needs calibration data not to calibrate for the internal sensor (that is always accounted for, even in "raw" data, which actually isn't as raw as you might think). It is actually to calibrate for external factors that might disrupt or interfere with the Earth's natural magnetic field, like high voltage power lines, or steel beams overhead. The iPhone creates a 3D distortion map of the field (which is why the compass app asks you to make a figure eight) to offset these external influences.
Finally, even if you could recreate the exact distortions, Apple provides no way to peek into their black-box filtering, let alone apply your own distortion map to their data. So no, you cannot recompute the calibrated data after the fact.
I want to find the cardinal direction accelerated by an iphone. I thought I could just use the accelerometer to do this, however, as you can see from the picture below the accelerometers axes are defined by the device orientation.
I figured that if i used the gyroscope to correct for yaw, spin, rotation then I could get a more accurate reading and not have to hold the phone in the same orientation during movement.
But this still does not tell me what cardinal direction the iphone is moving in. For that I would also have to use the the magnetometer.
Can anybody tell me how to use a three sensor readings to find the cardinal direction accelerated in? I dont even know where to start. I dont even know if the phone takes these measurements at the same rates of time either.
Taking the cross product of the magnetometer vector with the "down" vector will give you a horizontal magnetic east/west vector; from that, a second cross product gets the magnetic north/south vector. That's the easy part.
The harder problem is tracking the "down" vector effectively. If you integrate the accelerometers over time, you can filter out the motion of a hand-held mobile device, to get the persistent direction of gravity. Or, you could, if your device weren't rotating at the same time...
That's where the rate gyros come in: the gyros can let you compensate for the dynamic rotation of the hand-held device, so you can track your gravity in real-time. The classic way to do this is called a Kalman filter, which can integrate (both literally and figuratively) multiple data sources in order to evaluate the most likely state of your system.
A Kalman filter requires a mathematical model both of your physical system, and of the sensors that observe it; each of these models must be both accurate and "sufficiently linear" for the Kalman filter to work properly. As it happens, the iphone/accelerometer/gyro system is in fact sufficiently linear.
The Kalman filter uses both calculus and linear algebra, so if you're rolling your own, you will need a certain amount of math.
Also, as a practical matter, you should understand that physical sensors typically have offsets that need to be compensated for -- in particular, you need to pay attention to the rate gyro offsets in this kind of inertial navigation system, or your tracker will never stabilize. This means you will need to add your rate gyro offsets to your Kalman state vector and system model.