Merge pull request #176779 from qm13/updates

Fixes

Author: PMEds28

articles/kinect-dk/body-joints.md

@@ -20,13 +20,14 @@ Joint position and orientation are estimates relative to the global depth sensor
 
 ## Joint coordinates
 
-The position and orientation of each joint form its own joint coordinate system. All joint coordinate systems are absolute coordinate systems relative to the depth camera 3D coordinate system.
+The position and orientation of each joint form its own right-handed joint coordinate system. All joint coordinate systems are absolute coordinate systems in the depth camera 3D coordinate system.
 
 > [!NOTE]
-> Joint coordinates are in axis orientation. Axis orientation is widely used with commercial avatars, game engines, and rendering software. Using axis orientation simplifies mirrored movements e.g. raise both arms by 20 degrees.
+> The choice of flipped axis orientation for corresponding joints across the two sides of the body is intended to simplify mirror movement e.g. raise both arms by +20 degrees, which is common with commercial avatars, game engines, and rendering software.
 
 ![Joint coordinates](./media/concepts/joint-coordinates.png)
 
+x-axis - <span style="color: red;">red</span>; y-axis - <span style="color: green;">green</span>; z-axis - <span style="color: blue;">blue</span>
 ## Joint hierarchy
 
 A skeleton includes 32 joints with the joint hierarchy flowing from the center of the body to the extremities. Each connection (bone) links the parent joint with a child joint. The figure illustrates the joint locations and connection relative to the human body.

articles/kinect-dk/hardware-specification.md

@@ -150,7 +150,7 @@ Vendor ID is 0x045E (Microsoft). Product ID table is shown below:
 
 |    USB Interface        |    PNP IP    |     Notes            |
 |-------------------------|--------------|----------------------|
-|    USB3.1 Gen1 Hub    |    0x097A    |    The   main hub    |
+|    USB3.1 Gen2 Hub    |    0x097A    |    The   main hub    |
 |    USB2.0 Hub         |    0x097B    |    HS   USB          |
 |    Depth camera       |    0x097C    |    USB3.0            |
 |    Color camera       |    0x097D    |    USB3.0            |

articles/kinect-dk/media/concepts/joint-coordinates.png

@@ -80,7 +80,7 @@ In the image capture loop, avoid repeatedly setting the same exposure setting. C
 
 When multiple depth cameras are imaging overlapping fields of view, each camera must image its own associated laser. To prevent the lasers from interfering with one another, the camera captures should be offset from one another by 160μs or more.
 
-For each depth camera capture, the laser turns on nine times and is active for only 125μs each time. The laser is then idle for either 14505μs or 23905μs, depending on the mode of operation. This behavior means that the starting point for the offset calculation is 125μs.
+For each depth camera capture, the laser turns on nine times and is active for only 125μs each time. The laser is then idle for either 1450μs or 2390μs, depending on the mode of operation. This behavior means that the starting point for the offset calculation is 125μs.
 
 Additionally, differences between the camera clock and the device firmware clock increase the minimum offset to 160μs. To calculate a more precise offset for your configuration, note the depth mode that you are using and refer to the [depth sensor raw timing table](hardware-specification.md#depth-sensor-raw-timing). By using the data from this table, you can calculate the minimum offset (the exposure time of each camera) by using the following equation:
 
@@ -91,7 +91,7 @@ When you use an offset of 160μs, you can configure up to nine additional dept
 In your software, use ```depth_delay_off_color_usec``` or ```subordinate_delay_off_master_usec``` to make sure that each IR laser fires in its own 160μs window or has a different field of view.
 
 > [!NOTE]  
-> The actual pulse width is 125us however we state 160us to provide for some leeway. Taking NFOV UNBINNED as an example, each 125us pulse is followed by 1450us idle. Totaling these up - (9 x 125) + (8 x 1450) - yields the exposure time of 12.8ms. The closet you can interleave the exposure of 2 devices is to have the first pulse of the second camera to fall in the first idle period of the first camera. The delay between the first and second cameras could be as little as 125us (the width of a pulse) however we recommend some leeway hence the 160us. Given 160us you can interleave the exposure periods of a maximum of 10 cameras.
+> The actual pulse width is 125μs however we state 160us to provide for some leeway. Taking NFOV UNBINNED as an example, each 125μs pulse is followed by 1450μs idle. Totaling these up - (9 x 125) + (8 x 1450) - yields the exposure time of 12.8ms. The closet you can interleave the exposure of 2 devices is to have the first pulse of the second camera to fall in the first idle period of the first camera. The delay between the first and second cameras could be as little as 125μs (the width of a pulse) however we recommend some leeway hence the 160μs. Given 160μs you can interleave the exposure periods of a maximum of 10 cameras.
 
 ## Prepare your devices and other hardware