{"id":836,"date":"2018-03-05T02:48:39","date_gmt":"2018-03-05T02:48:39","guid":{"rendered":"http:\/\/mrsdprojects.ri.cmu.edu\/2017teami\/?page_id=836"},"modified":"2018-05-10T21:12:32","modified_gmt":"2018-05-10T21:12:32","slug":"system-design-3-4-2018","status":"publish","type":"page","link":"https:\/\/mrsdprojects.ri.cmu.edu\/2017teami\/system-design-3-4-2018\/","title":{"rendered":"System Design 5\/9\/2018"},"content":{"rendered":"

Functional Architecture<\/h4>\n

\"\"<\/p>\n

 <\/p>\n

\n
\n
\n

There are three inputs to the system. Firstly, a well-defined map of the environment, in which the rovers will operate, is provided as input to the system. Obstacles along with their locations are presented as part of this map. Secondly, a goal way point is provided as input which is the location to which the rovers shall attempt to navigate. Third, the rovers initial start position in the given environment map is entered (and included) as an input, which is later used to update the \u2018Rovers Current Position\u2019 module. Necessary information such as environment map, rover\u2019s current position and the goal location are fed into the \u2018Path Planner\u2019 block to determine a valid path for the rover to reach their respective goal waypoints. The \u2018Path Planner\u2019 block provides path planning functionalities for the symbiotic rovers system depending on specific scenarios encountered by the rovers as they traverse through the environment. These are explained as follows:<\/p>\n

\n
\n
\n
    \n
  1. A \u2018PreferredPath\u2019 is planned from the rover\u2019s current position to the goal position before the rovers start traversing through the environment.<\/li>\n
  2. Once the rovers start navigating through the environment (using the previously determined \u2018Preferred Path\u2019), the \u2018Behaviour Planning\u2019 module will modify the plan depending on the occurrence of either of the two following scenarios: a rover becomes stuck, or the current plan goes through a potentially \u2018Hazardous Zone\u2019. In the event a stuck rover scenario is observed, the behavior planning module shall generate an action plan for rescuing the stuck rover. In the event a rover perceives an approaching \u2018Hazardous Zone\u2019, the behavior planning module shall generate an action plan for both the rovers to couple together and traverse through that hazardous zone in a \u201dsafe\u201d manner.<\/li>\n
  3. In the event none of these special scenarios are encountered, the \u2018Behavior Planning\u2019 module shall simply output the \u2018Preferred Path\u2019 planned previously.<\/li>\n<\/ol>\n
    \n
    \n
    \n

    The \u2018Behaviour Planning\u2019 module outputs the planned path i.e. a trajectory of rover positions (set of way points\/ array of poses) that the rover should follow in order to efficiently reach the desired goal point. This trajectory is fed into the \u2018Motion Controller\u2019 module for physical execution of the planned path on the rovers. Consequently, the rovers start navigating through the environment following the planned path obtained from the \u2018Behaviour Planning\u2019 module. While the rovers are navigating through the environment, they continuously localize themselves and update their current positions (\u2018Rovers Current Position\u2019 module) in the existing map. In the course of their navigation through the environment, \u2018Entrapment Detection\u2019 is carried out continuously. Detection of entrapment of any rover marks the observation of \u2018Unforeseen Stuck Rover\u2019 scenario.<\/p>\n

    \n
    \n
    \n

    As the rovers traverse through the environment, an on-board camera provides a live video feed which forms part of the output of the Functional Architecture. Also, by virtue of the \u2018Motion Controller\u2019 module enabling the rovers to follow the planned path, the other outputs of the Functional Architecture include rovers safely navigating through the hazardous zones and performing rescue operation as the situation demands.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

     <\/p>\n

    Cyberphysical Architecture<\/h4>\n

    \"\"<\/p>\n

     <\/p>\n

    \n
    \n
    \n

    At a high level, the system is divided into two parts: mobile rovers which execute motion commands and collect information about their environment, and a stationary base station which communicates with the rovers wirelessly and performs data synthesis and any computationally complex calculations.<\/p>\n

    \n
    \n
    \n

    Our base station laptop will load our stored map of the test environment, and is responsible for hosting our roscore process. After loading the map and receiving initial pose data from the rovers, the base station will generate a path through the environment. The base station also analyzes rover telemetry with a Bayesian classifier to determine if one of the rovers is stuck, and if needed adjusts the rover path to the stuck rover. The planned trajectory is sent over to each rover via Wi-Fi, where an on-board computer uses it and its own telemetry data to perform a rudimentary closed loop positioning control. Both the base station and the rovers have control over the towing winch and claw. Towing behaviors are controlled from the base station, but the claws will close automatically if they detect something has entered their grabbing envelope to avoid potential latency issues.<\/p>\n

    \n
    \n
    \n

    The rovers carry the following sensors: wheel encoders, RTK GPS, an IMU, an RGB camera, and an HTC Vive VR system lighthouse and associated photodiodes. The primary purpose of all sensors save the camera are for localization purposes, and all but the camera are run through an EKF. The rovers use a double Ackermann drive system for steering, and both the motor attached to the rack-and-pinion and the motor attached to the transmission are controlled by a Roboclaw motor driver, which performs its own PID control on the drive motor velocity. On-board processing is performed by an ODROID XU4 single board computer, and control of the towing winch and claw servos is achieved over a serial connection to an Arduino UNO.<\/p>\n

     <\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

     <\/p>\n","protected":false},"excerpt":{"rendered":"

    Functional Architecture   There are three inputs to the system. Firstly, a well-defined map of the environment, in which the rovers will […]<\/p>\n","protected":false},"author":118,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-836","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/mrsdprojects.ri.cmu.edu\/2017teami\/wp-json\/wp\/v2\/pages\/836","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mrsdprojects.ri.cmu.edu\/2017teami\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/mrsdprojects.ri.cmu.edu\/2017teami\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/mrsdprojects.ri.cmu.edu\/2017teami\/wp-json\/wp\/v2\/users\/118"}],"replies":[{"embeddable":true,"href":"https:\/\/mrsdprojects.ri.cmu.edu\/2017teami\/wp-json\/wp\/v2\/comments?post=836"}],"version-history":[{"count":4,"href":"https:\/\/mrsdprojects.ri.cmu.edu\/2017teami\/wp-json\/wp\/v2\/pages\/836\/revisions"}],"predecessor-version":[{"id":964,"href":"https:\/\/mrsdprojects.ri.cmu.edu\/2017teami\/wp-json\/wp\/v2\/pages\/836\/revisions\/964"}],"wp:attachment":[{"href":"https:\/\/mrsdprojects.ri.cmu.edu\/2017teami\/wp-json\/wp\/v2\/media?parent=836"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}