![\"cyberarch\"](\"http:\/\/mrsdprojects.ri.cmu.edu\/2015teamj\/wp-content\/uploads\/sites\/11\/2015\/10\/cyberarch.png\")
<\/p>\n<\/p>\n
<\/p>\n
Figure: Software Architecture Block Diagram<\/p>\n
<\/p>\n
Subsystem descriptions:<\/strong><\/p>\n Vision Subsystem:<\/em><\/p>\n The vision subsystem is responsible for the detection of the ship deck and its relative pose.\u00a0At long ranges, the position will be determined using the camera on the rotorcraft and the IR\u00a0beacons on the corners of the deck. At medium range, all four of the IR beacons will be distinct\u00a0enough for the camera to interpret individually. Finally, at close range, the known beacon pattern at the\u00a0center of the deck will be sensed using the cameras. Alternatively, the vision subsystem could be\u00a0replaced or augmented with radar and lidar components. However, the cost and complexity of\u00a0these components is prohibitively expensive given their relatively minor benefits over the\u00a0proposed subsystem.<\/p>\n Deck Marking Subsystem:<\/em><\/p>\n The deck marking subsystem is responsible for indicating several points of interest on the\u00a0ship deck to the rotorcraft. The IR beacons on the corners of the deck provide an approximate\u00a0location at long distance due to their greater than .5 mile visibility. Once the rotorcraft is close\u00a0enough to distinguish between them, the center of the deck and the pose of the deck can be\u00a0determined based on the prior knowledge of their configuration on the deck. Accounting for the optics of the camera\u2019s lenses and their magnification, the scaled size and perspective warping of the beacons can also be used to calculate the distance to and relative position of the deck.<\/p>\n Localization Algorithm Subsystem:<\/em><\/p>\n The input to the localization algorithm will be the image from the short range landing camera, as well as the data from the rotorcraft IMU. Let long\u00a0range be the range within which the deck beacons are\u00a0within the field of view of the short range\u00a0landing camera.\u00a0Let prediction\u00a0range be the range beyond landing range, but within long range, within which the system will\u00a0attempt to perform prediction of the deck\u2019s motion. Let landing range be the range where the deck is too close to localize effectively.<\/p>\n While at long range, the algorithm will identify the centroid of the four beacons and\u00a0output the relative direction between the quadrotor and the centroid, using the known mounting\u00a0configuration of the cameras to construct a heading for the quadrotor.<\/p>\n Once within prediction range, in addition to outputting the centroid location as above, the\u00a0algorithm will also reconstruct the pose of the deck. To do this, the algorithm will identify the\u00a0centroid of the beacons to determine the deck\u2019s relative position as before. Then, relative pose\u00a0will be determined by perspective transform of the known configuration of beacons on the deck.\u00a0Finally, the \u201cabsolute\u201d motion of the deck from one frame to the next will be determined by\u00a0subtracting the quadrotor\u2019s motion model data from the corresponding frames. This accounts for\u00a0the motion of the quadrotor during the time between frames. This model is generated through a\u00a0combination of the corresponding motion command from the path planner to the flight controller\u00a0and the IMU data for the target time window. The prediction range algorithm will output both\u00a0the absolute and relative pose of the deck.<\/p>\n Finally, within landing range, the algorithm will attempt to compute the relative and absolute poses\u00a0as above, however, by this point we are likely incredibly close to the deck and need to be operating open-loop to land quickly.<\/p>\n Prediction Algorithm Subsystem:<\/em><\/p>\n The prediction algorithm will use the absolute pose of the deck over time to produce data of\u00a0roll, pitch, and swell over time. This data will be in reference to an absolute world frame\u00a0centered at the deck. The algorithm will then use a Kalman filter to predict the motion of the\u00a0deck into the future. This will allow the rotorcraft to plan a trajectory such that it meets the deck\u00a0at a relative high point and a relative flat point on the deck\u2019s path. This is critical in order to\u00a0perform a safe landing with minimal damage to the rotorcraft or the ship.<\/p>\n Trajectory Planning Subsystem:<\/em><\/p>\n The trajectory generation system is responsible for generating a trajectory from initial state to a target position. When the user triggers the autonomous landing system, the trajectory generation subsystem will receive current pose of the quadrotor from the localization subsystem and sets the pose as initial position. Then the trajectory generation subsystem will generate a trajectory based on a quintic polynomial from the initial position to the pre-defined goal position.<\/p>\n Trajectory Following Subsystem:<\/em><\/p>\n The trajectory following algorithm subsystem is responsible for detecting errors in our current flightpath and making the corresponding course corrections to put the rotorcraft back on the target trajectory generated by the trajectory generation algorithm.<\/p>\n The input command for the subsystem is the position trajectory generated by the trajectory generation algorithm, and the sensor feedback is the feedback data from state estimation algorithm. We use PD controller as feedback controller and use acceleration command generated by quintic polynomial as a feed-forward term. The advantage for using feedforward term is it can not only mitigate the following error but also decrease the amount of overshoot. Since there is an attitude controller controlled by DJI internally, we don\u2019t need to add additional inner loop to control the attitude.<\/p>\n Rotorcraft subsystem:<\/em><\/p>\n The rotorcraft is responsible for executing the command sent from the single board computer\u00a0such as flying, landing, and flight mode switching. The rotorcraft consists of flight avionics,\u00a0actuators, radio transmitter and receiver, vehicle frames, and battery. Flight Avionics is the brain\u00a0of the system; it consists of a processor, sensors, and input\/output (I\/O) pins. The basic sensor a\u00a0rotorcraft requires is the gyroscopes, which provides the angular information of the rotorcraft.<\/p>\n However, without the accelerometer, the user needs to manually control the orientation of the\u00a0rotorcraft. Typically, most flight controllers apply proportional-integral-derivative (PID) control\u00a0for stabilization of the rotorcraft. The I\/O pins are responsible for providing connections of\u00a0actuators and command receiver to the processor. In this work, there are two inputs responsible\u00a0for the dynamic movement of the rotorcraft. One is the trajectory command send by single board\u00a0computer while the other one is from radio transmitter in case of emergency. For actuators,\u00a0brushless dc motors are used; each of the motors is driven by electronic speed controller. The\u00a0thrust of the vehicle is provided by attaching propellers on the motors.\u00a0In the ideal situation, the rotorcraft should autonomously follow the exact planned trajectory\u00a0under the influence of natural disturbance and in EMCON condition. Therefore, dynamic\u00a0stability of the rotorcraft is the primary concern in this work since any disturbance to the\u00a0rotorcraft could result in bias to the sensors. In the scope of rotorcraft platform trade study, the\u00a0disturbances include wind, payload variation, and other factors. The rotorcraft should provide enough\u00a0maneuverability and stability with the installation of single board computer, sensors and battery.\u00a0Moreover, the landing gear should withstand multiple tests; so the cost can be minimized and the\u00a0components can be protected. Finally, the application programming interface (API) and\u00a0community support of the rotorcraft platform can be great sources to reduce development time.<\/p>\n","protected":false},"excerpt":{"rendered":" Figure: Software Architecture Block Diagram Subsystem descriptions: Vision Subsystem: The vision subsystem is responsible for the detection of the ship deck and its relative pose.\u00a0At long ranges, the position will be determined using the camera on the rotorcraft and the IR\u00a0beacons on the corners of the deck. At medium range, all four of
+ Read More<\/a><\/p>\n","protected":false},"author":16,"featured_media":0,"parent":18,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"template_parts\/page-fullwidth_template.php","meta":{"footnotes":""},"class_list":["post-140","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/mrsdprojects.ri.cmu.edu\/2015teamj\/wp-json\/wp\/v2\/pages\/140","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mrsdprojects.ri.cmu.edu\/2015teamj\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/mrsdprojects.ri.cmu.edu\/2015teamj\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/mrsdprojects.ri.cmu.edu\/2015teamj\/wp-json\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/mrsdprojects.ri.cmu.edu\/2015teamj\/wp-json\/wp\/v2\/comments?post=140"}],"version-history":[{"count":14,"href":"https:\/\/mrsdprojects.ri.cmu.edu\/2015teamj\/wp-json\/wp\/v2\/pages\/140\/revisions"}],"predecessor-version":[{"id":630,"href":"https:\/\/mrsdprojects.ri.cmu.edu\/2015teamj\/wp-json\/wp\/v2\/pages\/140\/revisions\/630"}],"up":[{"embeddable":true,"href":"https:\/\/mrsdprojects.ri.cmu.edu\/2015teamj\/wp-json\/wp\/v2\/pages\/18"}],"wp:attachment":[{"href":"https:\/\/mrsdprojects.ri.cmu.edu\/2015teamj\/wp-json\/wp\/v2\/media?parent=140"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}