{"id":16,"date":"2022-11-13T01:42:55","date_gmt":"2022-11-13T01:42:55","guid":{"rendered":"https:\/\/mrsdprojects.ri.cmu.edu\/2023teamb\/?page_id=16"},"modified":"2023-05-07T03:51:56","modified_gmt":"2023-05-07T03:51:56","slug":"system-design","status":"publish","type":"page","link":"https:\/\/mrsdprojects.ri.cmu.edu\/2023teamb\/system-design\/","title":{"rendered":"System Design"},"content":{"rendered":"\n

The system-level requirements of DarkBot are derived from the use case and objective tree. The requirements include functional, performance, and nonfunctional ones, and each of them is divided into mandatory and desirable requirements. By the end of the fall semester, we would achieve all mandatory requirements. The desirable requirements are initially out of scope, but they will significantly enhance the performance of the system. The team will try its best to achieve them as much as possible.<\/p>\n\n\n\n

All requirements have been discussed and reviewed by stakeholders to make sure that they are realistic and doable for the project. Note that those requirements are not finalized and will be changed according to future research and tests.<\/p>\n\n\n\n

System Requirements<\/strong><\/p>\n\n\n\n

\n
\n

Mandatory Functional Requirements<\/p>\n\n\n\n

\"\"<\/figure>\n<\/div>\n\n\n\n
\n

Desirable functional requirements<\/p>\n\n\n\n

\"\"<\/figure>\n<\/div>\n<\/div>\n\n\n\n

Performance Requirements<\/strong><\/p>\n\n\n\n

\n
\n

Mandatory Performance Requirements<\/p>\n\n\n\n

\"\"<\/figure>\n<\/div>\n\n\n\n
\n

Desirable Performance Requirements<\/p>\n\n\n\n

\"\"<\/figure>\n<\/div>\n<\/div>\n\n\n\n

Non-functional Requirements<\/strong><\/p>\n\n\n\n

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

\n
\n

Mandatory Nonfunctional Requirements<\/p>\n\n\n\n

\"\"<\/figure>\n<\/div>\n\n\n\n
\n

Desirable Nonfunctional Requirements<\/p>\n\n\n\n

\"\"<\/figure>\n<\/div>\n<\/div>\n\n\n\n

Functional Architecture<\/strong><\/p>\n\n\n\n

Autonomous exploration and human localization are the system’s core high functions to solve our use case. To accomplish such functions, we compiled the functional architecture from function requirements accordingly. The functional architecture diagram is shown in Figure 1. From a black-box perspective, the system takes in the environment information, operator inputs, and electricity, and outputs robot terrain traversal, a 3D map with robot and detected human poses, etc. This architecture can be broken down into three parallel pipelines: perception-based planning (top), SLAM (middle), and human detection and localization (bottom).<\/p>\n\n\n\n

The perception-based planning pipeline (top) first performs a terrain analysis about the surrounding environment of the robot to generate a 2.5D elevation map. This map is used as a prior to a more efficient motion planning that executes the local trajectories and global exploration route generated by the Navigation module, given the 3D map and robot pose from the second pipeline. Second, the SLAM pipeline (middle) continuously builds a 3D environment map with a robot pose estimation from collected sensor data. The map and robot pose serves as a foundation for explorations (top) and human localization (bottom). Third, the human detection and localization pipeline uses color-and-depth image stream data to detect humans in robot’s field of view and localize them in the global 3D map. This end-user will see human location pins on the 3D map, which is achieved with robot pose, human pose estimation relative to the robot, and the visualized 3D map. Last but not least, an operator would have overriding teleoperation access to intervene and control the robot during any circumstances.<\/p>\n\n\n

\n
\"\"
Figure 1. Functional Architecture<\/figcaption><\/figure>\n<\/div>\n\n\n

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

Cyberphysical Architecture<\/strong><\/p>\n\n\n\n

Building upon the conclusions in our trade studies, the cyber-physical architecture as shown in Figure 2 realizes our requirements by combining the functional architecture with the Unitree Go1\u2019s hardware architecture and the sensor payload. The main components of the system are divided into the eight parts: Safety, Simultaneous Localization and Mapping, State Estimator, Human Detection, Video Feedback, Power, Plan and Traverse, Information Process, and User Command.<\/p>\n\n\n

\n
\"\"
Figure 2: Cyberphysical Architecture<\/figcaption><\/figure>\n<\/div>\n\n\n

System Design<\/strong><\/p>\n\n\n\n

Elevation Mapping and State Estimation Subsystem<\/h3>\n\n\n\n

Following the cyber-physical architecture, the simultaneous localization and mapping (SLAM) module should take 3D LiDAR scans, IMU reading, and Stereo camera data as input and maintain a 3D world map with estimated robot pose. It serves as the foundation for search and rescue exploration through narrow spaces and upon terrains with elevation changes. The SLAM architecture should be robust and reliable as the map grows larger, as well as consistent on runtime and memory consumption to guarantee real-timeness. Further based on the trade study, our SLAM architecture will likely follow the standard formulation proposed in LIO-SAM, which stands for Tightly-coupled Lidar Inertial Odometry via Smoothing and Mapping. <\/p>\n\n\n\n

LIO-SAM formulates lidar-inertial odometry on top of a factor graph, enabling both relative and absolute measurements, to perform pose graph joint optimizations and loop closures. The tightly coupled IMU provides nonlinear motion pre-integration to de-skew point clouds, initialization of odometry optimization, and most importantly contributes to part of the factor graph for bundle adjustments. The result of lidar odometry optimization can conversely be utilized to estimate the bias of IMU in the factor graph. To ensure the real-timeliness without sacrificing accuracies, LIO-SAM uses edge and plane features as descriptors proposed by LOAM for 3D lidar scans and achieves critical efficiency in the following:<\/p>\n\n\n\n

Computing Lidar Odometry Factor:<\/strong><\/h3>\n\n\n\n