T265 Occlusion Zones
I have an application where I need to mount the T265 to a machine that has parts that move in the view of the camera. These parts are in predictable zones from the view of the camera. Is there a way to tell the T265 to ignore these portions of the view when collecting visual data?
-
T265 questions are now handled by the RealSense GitHub forum. You can post your question there by visiting the link below and clicking the 'New Issue' button.
https://github.com/IntelRealSense/librealsense/issues
Having said that, if you only need data for an area in front of the zone where the view gets occluded then I wonder if you could set up a Threshold Filter to define a minimum and maximum observable range that excludes data relating to all areas outside of that range.
I have not got a T265 to get this with. You could try opening the RealSense Viewer program, going to the 'Post Processing' section of the options side-panel and expanding open the Threshold Filter option, if it is present when a T265 is attached to the computer. I can also provide links to setting up a Threshold Filter in code if you need it.
A more complex way of setting up zones that are ignored is to define 'bounding boxes' that ignore data outside of the boxes.
The T265 also offers the option of tracking specific areas or moving objects (e.g a mechanical digger's shovel) by applying trackable Apriltag images to the areas that you want to track.
https://github.com/IntelRealSense/librealsense/tree/master/examples/pose-apriltag
-
I did a poor job explaining my question, my apologies.
Here is a picture of my application. The picture on the left is what a person would see if they were looking forward from that position. I'm not sure what the fisheye lenses would see. The pink bar on the right shows where I would ideally mount the T265.
The caster beam can rotate about the center bolt and so the camera will be seeing motion in these areas. But the motion should be predictable. Can I program the camera (I don't have one yet, getting ready to order one) to ignore these areas?
Thanks Marty!
Drew
-
No problem at all, don't worry!
The RealSense SDK's ar-advanced sample program for the T265 gives an example of what a moving fisheye view might look like.
https://github.com/IntelRealSense/librealsense/tree/master/examples/ar-advanced
I assume that the height that the camera is mounted at is important and it is not practical to mount the T265 on a pole to elevate its view above the pivoting caster beam.
I did some tests with 4 wheeled chairs and trollies to get a sense of how this approach might be adapted to avoid observing the beam.
I wonder if it would be feasible to reverse the direction of travel of the cart, so that the caster beam is the back axle that turns and the non-beam fixed position wheels are the front wheels. Then the computing unit and camera are turned around 180 degrees and put at the new front, where the T265 would have an unobstructed view.
When the back caster wheels turn, the front of the cart turns in the direction that the back wheels are pointing in. In other words, the back wheels are acting like the rear steering rudder on a boat.
-
The T265 does not do depth or distance calculations as it does it have depth sensing. Its calculations are based on factors such as image cues / patterns in the observed environment and motion and angle data from its internal Inertial Measuring Unit (IMU).
I would imagine that if it was mounted backwards then it would indeed experience forward motion on the cart as though it was travelling backwards. Pose is a calculation involving the XYZ position and the XYZW quaternion angle of an observed object though. So rear-facing mounting should affect the pose calculation in the sense that as the cart moves forward the detected object position will get further away, and closer when the cart is reversing.
Please sign in to leave a comment.
Comments
5 comments