FVD Performance
The FVD functional performance requirements covers all subsystems including fleet management, perception, task allocation / generation, localization and navigation, and GUI. Since during SVD we had already met many of our performance requirements, the only ones left for FVD were:
M.F.0. | System shall identify and localize victims in environment using fiducial markers within desired rescue time. |
M.P.1. | System will detect 75% of victims in the environment. |
M.P.2. | System will localize victim position within 5 meters. |
M.N.2. | System shall visualize the environment, locations of victims, and robot agents during operation. |
For FVD, we expanded our system to satisfy our desirable requirements:
D.F.0. | System shall map and search in unknown environment simultaneously during operation. |
D.N.2. | System shall support heterogenous robot search and control. |
We satisfied the mandatory requirements by building our perception system, which was able to detect Apriltags that represented victims and report the agent’s current location at detection time. The distance between the reported position and true victim position is guaranteed to be < 5m since the camera detection only has a range of ~4m, satisfying M.F.0, M.P.2.
We also satisfied requirement M.N.2 by implementing a Mission Control GUI that visualizes agent states, task allocation, mission status, and user controls.
We overhauled our localization subsystem from SVD to become a SLAM system, or more specifically a multi-robot SLAM system (MRSLAM). This means the robots are able to map an unknown environment while also localizing themselves within the map they are currently building. We used a pose-graph based implementation expanded from the popular ROS package slam_toolbox. Our new MRSLAM system therefore satisfies D.F.0.
Additionally, our system now supports heterogenous robot search and control (D.N.2). We pivoted from planning-based navigation stack to a control-based approach. This means instead of doing centralized path planning and decentralized control, we are now doing decentralized planning and centralized control. An A* path is computed individually for each robot in a decentralized fashion. Our new Lazy Traffic Controller (LTC) then computes velocity commands for each agent in a centralized way that allows them both to follow their desired trajectory while also avoiding collisions with other agents and obstacles. We combine velocity obstacles and repulsion forces to effectively make a robust multi-robot controller.
Through both simulation and real life testing, we were able to verify that the system consistently detects more than 75% of the victims in the environment (M.P.1). In fact, through 15 simulation runs, our system on average detects 97% of victims within 8 minutes of search time. Additionally, we benchmarked our novel task allocator (named HIGH) against a naive algorithm (greedy), and saw that HIGH on average performed 26% better than naive with our Sum of Search Times (SST) metric. Additionally, HIGH also on average has a 35% lower standard deviation of SST, meaning that it is much more consistent and repeatable.
SVD Performance
The SVD functional performance requirements covered all subsystems including fleet management, task allocation / generation, localization and navigation. The performance requirements related to both swarm control as well as perception are left for the fall semester. Non functional requirements related to the human robot interaction are also left in the plan for the fall semester.
We were successfully able to demonstrate all the above requirements during SVD and SVD encore!
The system performed very well. It operated robustly, quickly, and intelligently, meeting all the goals we set for the spring semester at SVD Encore. Of note is M.P.6., which we used to quantify if our search was fast enough; to search 175 m2, the requirement necessitates completion in 7.5 minutes, but we were able to complete the search in just 3.5 minutes, fulfilling the requirement with plenty of time to spare. M.P.2. was the only requirement not met at SVD, but after optimizing the way tasks are assigned to agents, we were able to fulfill the requirement at SVD Encore. M.F.2. and M.F.4. were also demonstrated and fulfilled at SVD and SVD Encore by demoing with varying numbers of agents, and by killing an agent in the middle of operation.
M.F.1. | System shall localize robots with a known map of the environment. |
M.F.2. | System shall dynamically allocate tasks to agents in the fleet for optimizing time required for the search. |
M.F.3. | System shall ensure simultaneous navigation of agents which have been allocated a task. |
M.F.4. | System shall adapt to changes in the fleet size like addition of agents by the users or loss of robots during operation. |
M.P.3. | System will finish searching the environment 20% faster than the naive algorithm for a typical indoor environment. |
M.P.2. | System will have downtime of less than 5s for busy agents. |
M.P.4. | System will update agent status for the user at 1Hz frequency. |
M.P.5. | System will handle at least 3 agents in the fleet. |
M.P.6. | System will have a search speed of at least 70 m2 in 3 minutes |