Refined Use Case: Urban disaster area search for a single operator
(Definition of Search: reducing the area a Search and Rescue Team believes there will be a survivor)
Our team has finished our requirements and our design that satisfies those requirements to fit this newly refined use-case. It looks very similar to what we displayed in previous posts, but with key considerations noted below:
We are keeping the two motor per arm implementation. While our emphasis is not on being agile anymore, it is still more desirable to get over rubble that will be very likely present than to be limited to what our wheels can get over.
We have moved away from needing to care as much about size, as our use case does not necessitate it to be that small anymore. However, we still need to be mindful of cost. But, this gives us room to have a larger battery, and overall better equipment.
We are not doing fancy things like having the robots attach or jump anymore, as cool as that would be, it is not feasible for our MVP (and Josh is not a MechE)
We are using UWB as our primary method of localization / sensing, and for that to function it needs anchors. Anchors need to be stationary, and you typically need at least 3 to have readings at cm accuracy (which we want as all error accrues over time). Therefore, a working system will need at least 4 functional robots (3 that stay still while the other moves). In initial testing and our MVP we only need two to move and prove the distributed system effective, the rest can be stationary.
Our UI will be visualizing the paths that our robots have followed, and give color to those lines based on their proximity to a person (our MVP will be using a stationary anchor not ascribed to a bot). We will not be doing complicated SLAM things.