{"id":279,"date":"2015-10-23T13:56:59","date_gmt":"2015-10-23T17:56:59","guid":{"rendered":"http:\/\/mrsdprojects.ri.cmu.edu\/2015teami\/?page_id=279"},"modified":"2016-05-06T19:36:55","modified_gmt":"2016-05-06T23:36:55","slug":"sensing-subsystem","status":"publish","type":"page","link":"https:\/\/mrsdprojects.ri.cmu.edu\/2015teami\/sensing-subsystem\/","title":{"rendered":"Sensing and Perception Subsystem"},"content":{"rendered":"

The sensing and perception subsystem\u2019s main objective is to collect data to aid in localization, navigation, spot detection, and obstacle avoidance.\u00a0 The generation of the environment map is also a key aspect of the project, which the system will accomplish through Asus Xtion.<\/p>\n

<\/a>Sensing Hardware<\/h2>\n

Function<\/strong>: Spot Detection, Odometry, Obstacle Avoidance<\/p>\n

We will use an Asus Xtion depth camera to acquire images and generate point clouds.\u00a0 The device features an “RGB camera, depth sensor and multi-array microphone running proprietary software”, which provide full-body 3D motion capture, facial recognition, and voice recognition capabilities.\u00a0 The depth sensor consists of an infrared laser projector combined with a monochrome CMOS sensor, which captures video data in 3D under any ambient light conditions.\u00a0 The sensing range of the depth sensor is adjustable, and\u00a0Xtion software is capable of automatically calibrating the sensor based on the physical environment.<\/p>\n

The camera will primarily be used to detect the spot in which a platform will park.\u00a0 By combining the data from ultrasonic sensors and vision system, the exact location of the obstacle can be calculated.\u00a0 This will augment the path planning algorithm\u2019s obstacle avoidance capability.<\/p>\n

Vision-based odometry using monocular or stereo vision cameras will help in localization and avoiding other moving vehicles in the lot.\u00a0 The data from encoders when coupled with visual feedback from the sensors will help in generating a reliable estimate of the robot\u2019s position.<\/p>\n

\"\"<\/a>

Asus Xtion depth camera<\/p><\/div>\n

<\/a>Obstacle Detection using Asus Xtion<\/h3>\n

The obstacles are defined to be cylinders of 10-50 cm height and 10-120 cm diameter. Our algorithm uses plane fitting of a cylinder model and RANSAC for outlier rejection to segment out cylindrical objects from the point cloud. To increase the performance of the system, the incoming data from\u00a0Xtion is down-sampled using a voxel grid-based approach. Further filtering is done to retain only a region of interest for the purposes of obstacle detection and crop out everything else. This data is then passed through VoxelGrid and PassThrough filters so that the foreground objects can clearly be differentiated from background objects, such as walls.\u00a0The objective of this node is to publish the detection of an obstacle on an emergency topic.<\/p>\n

\"obst_kinect\"<\/a>

a) Raw Data b) Segmented Cylinder<\/p><\/div>\n

Obstacle Detection using Laser Range Finder<\/h3>\n

The LRF module consists of a laser, a CMOS camera and an onboard processor. The module works by emitting a beam of laser which is detected by the camera. The exact depth of the point is estimated by triangulation. When we sweep the laser incrementally between two angles, we would be detecting obstacles that would be half a meter in front of our platform. The subsystem uses a dedicated ROS node which parses and checks the reading from the sensor and declares emergency appropriately.
\n\"servo\"<\/a><\/p>\n

Diagram depicting servo-LRF sweeping<\/p>\n

The above figure\u00a0depicts the calculations related to the rotation angle of the LRF. This shows that the servo needs to sweep an area of +\/- 35 degrees from the center of the platform. To do this, mounts were created to attach the LRF to the servo.<\/p>\n

\"lrf\"<\/a><\/h3>\n

LRF with 3D Printed Mounts<\/p>\n

Obstacle Detection using IR<\/h3>\n

A dedicated proximity detection subsystem is used to prevent collisions with close-range obstacles.\u00a0 The system is implemented in the form of a plug-and-play PCB with sensors and a microcontroller to interpret the readings of the sensors.\u00a0 The system is designed to detect obstacles that are within 50 cm of the platform and cannot be detected using point-cloud data from the\u00a0Xtion.\u00a0 Any obstacle less than 20 cm causes an emergency to be declared in the system, making the locomotion come to a complete halt.\u00a0 Three IR sensors are mounted on the front of the platform. A dedicated Printed Circuit Board (PCB) was also designed to integrate the IR sensors within the system.\u00a0 The PCB houses an Arduino Nano, voltage regulation unit, and connectors for a power supply and three IR sensors.\u00a0 Open headers are present on the PCB for debugging and the addition of new peripherals.<\/p>\n

\"ir_mount\"<\/a>

Mounted IR Sensors<\/p><\/div>\n

 <\/p>\n

The Arduino operates as a ROS node and interfaces with the IR sensors to publish time-stamped range data on a ROS topic.\u00a0 This involves polling the three IR sensors and publishing the range data if the range is less than 50 cm.\u00a0 A separate \u201cemergency\u201d ROS node running on the SBC interprets range data and publishes the current state of the emergency.\u00a0 Figure 40 depicts the time-stamped range data being published on the left terminal window and the corresponding emergency state on the right.\u00a0 An emergency state of \u201c0\u201d indicates that no emergency has been detected and the system can continue normal operation.\u00a0 When a \u201c1\u201d is published on the \u201cemergencyState\u201d topic, the system is in a state of emergency and needs to stop immediately.<\/p>\n

 <\/p>\n

\"pcd_design\"<\/a>

PCB Design- Rev 1<\/p><\/div>\n

\"pcb_actual\"<\/a>

Manufactured PCB 1<\/p><\/div>\n

 <\/p>\n

The first revision of the PCB performed really well and also served as a source to power additional components like USB hubs.Additional components, like the USB hub, had not been taken into account during the design of the first iteration of the PCB as it was assumed that they would be powered by either USB or through Oculus Prime\u2019s power distribution board. Further shortcomings of the board included not having LEDs for diagnostics and dedicated fuses for lines powering the USB hubs. In addition to this, the PCB lacked additional connectors for powering other devices.<\/p>\n

To mitigate this problem, a second revision of the\u00a0PCB was designed to include-<\/p>\n