Trivial cleanups of doc/t265.md

Author: radfordi

doc/t265.md

@@ -1,6 +1,6 @@
 # T265 Tracking Camera
 
-The **Intel® RealSense™ Tracking Camera T265** includes two fisheye lens sensors, an IMU and an Intel® Movidius™ Myriad™ 2 VPU. All of the V‑SLAM algorithms run directly on the VPU, allowing for very low latency and extremely efficient power consumption (1.5W).
+The **Intel® RealSense™ Tracking Camera T265** includes two greyscale cameras with fisheye lens, an IMU, and an Intel® Movidius™ Myriad™ 2 VPU. All of the V‑SLAM algorithms run directly on the VPU, allowing for very low latency and extremely efficient power consumption (1.5W).
 
 RealSense SDK currently supports T265 on Windows and Linux as well as via our ROS wrapper.
 
@@ -20,11 +20,11 @@ To aid AR/VR integration, the T265 tracking device uses the defacto VR framework
 
 The center of tracking corresponds to the center location between the right and left monochrome imagers on the PCB.
 
-When T265 tracking starts, an origin coordinate system is created and RealSense SDK provides T265 poses relative to it. Origin's Y axis is always aligned with gravity and points to the sky. Origin's X and Z axes are not globally set, but determined when tracking starts depending on the initial orientation of the T265 device. The origin coordinate system is always right-handed.
+When T265 tracking starts, an origin coordinate system is created and RealSense SDK provides T265 poses relative to it. World's Y axis is always aligned with gravity and points to the sky. World's X and Z axes are not globally set, but determined when tracking starts based on the initial orientation of the T265 device with the initial -Z world axis as the projection of the camera axis to the ground plane.  This does mean that the initial yaw can seem random when the device is started in a downward facing configuration, say on the drone.   All T265 (and librealsense) coordinate systems are right-handed.
 
 ## Calibration
 
-The T265's sensors (including the IMU) are calibrated in the production line, so no further calibration process is required (unlike the D435i).
+The T265's sensors (including the IMU) are calibrated on the production line, so no further calibration process is required (unlike the IMU on the D435i).
 
 For reference, this is the orientation of each sensor:
 ![T265 Sensor extrinsics](./img/T265_sensor_extrinsics.png)
@@ -33,15 +33,15 @@ For reference, this is the orientation of each sensor:
 The following `librealsense` tools and demos are IMU and tracking-ready:
  - `rs-pose` - A basic pose retrieval example
  - `rs-pose-predict` - Demonstrates pose prediction using current system time and the callback API
- - `rs-capture` - 2D Visualization.  
- - `rs-enumerate-devices` - list the IMU and tracking profiles (FPS rates and formats).  
- - `rs-data-collect` - Store and serialize IMU and Tracking (pose) data in Excel-friendly csv format. The tool uses low-level sensor API to minimize software-imposed latencies. Useful for performance profiling.  
- - `realsense-viewer` - Provides 2D visualization of IMU and Tracking data. 3D visualization is available for Pose samples:  
+ - `rs-capture` - 2D Visualization.
+ - `rs-enumerate-devices` - list the IMU and tracking profiles (FPS rates and formats).
+ - `rs-data-collect` - Store and serialize IMU and Tracking (pose) data in Excel-friendly csv format. The tool uses low-level sensor API to minimize software-imposed latencies. Useful for performance profiling.
+ - `realsense-viewer` - Provides 2D visualization of IMU and Tracking data. 3D visualization is available for Pose samples:
 
-![T265 2D Sensors](./img/t265_snapshot.png)  
+![T265 2D Sensors](./img/t265_snapshot.png)
 ![T265 3D Pose Tracking](./img/t265_trajectory_tracker.gif)
 
-The IMU and Tracking data streams are fully compatible with SDK's embedded recorder utility.  
+The IMU and tracking data streams are fully compatible with SDK's embedded recorder utility.
 
 ## API
 The pose and IMU data are treated by the SDK like any other supported sensor. Therefore the sensor access and invocation API calls are similar to those of the depth/rgb sensors of D400 and SR300: