Team Status Report for 10/18

This week we made key changes to the hardware of the robot, switching to a more expensive yet reliable Yahboom robot chassis kit. It is ordered and on track to arrive by the time we return from Fall break to enable swift assembly and integration with code. Otherwise the hardware design is the same, just with different parts that have guaranteed compatibility and much wider documentation.

Additionally, the team worked towards completion of the Design Doc, taking feedback from the Design Presentation into account and ironing out any questions that remain unanswered in each respective sub-domain and submitting a thorough and well documented final product.

A was written by Zhuoyi Zou, B was written by Rachel Lewis and C was written by _____.

Part A:

Our mapping system addresses the need of maintaining accurate spatial information in warehouses and storage facilities as their layouts change. Organizations in different regions may have different facility sizes, staffing levels, technical expertise, and access to computing infrastructure. We are therefore designing the system around reusable ROS 2 components and configurable robot interfaces, allowing the architecture to be adapted without requiring every deployment to recreate the entire software stack. The proposed ability to continue mapping during communication interruptions is particularly relevant to facilities with inconsistent wireless coverage. Processing sensor data locally also reduces dependence on a continuously available remote computing service.

This also requires considering who will operate and maintain the system. We should not require warehouse personnel to understand SLAM algorithms or ROS commands to interpret results. We plan to provide configured visualizations of maps, robot status, exploration progress, and detected environmental changes. Documentation and repeatable setup procedures will help maintenance personnel distinguish hardware faults, communication problems, and mapping failures. Although our initial prototype will be evaluated in a controlled environment, deployment elsewhere would require validation against local facility conditions and practices.

Part B:

Our robot swarm is designed with cultural factors in mind by making the system accessible to warehouse employees with different technical backgrounds and language abilities. The alert interface will be intentionally simple and non-technical, communicating key information about warehouse floor changes, such as the affected region and the severity of a blockage, without relying heavily on English text. This makes the system easier to use across workplaces with multilingual employees or managers who may not have experience with robotics or mapping technology. The robots themselves are also small, simple, and generally non-threatening in appearance and function. Rather than replacing existing warehouse jobs, they perform a supporting role by monitoring the floorplan and identifying changes that could interfere with normal operations. In this way, the system is intended to help existing employees and workflows operate at full capacity rather than substitute automation for human labor.

Part C: … with consideration of environmental factors. Environmental factors are concerned with the environment as it relates to living organisms and natural resources.
*How much energy does continuous mapping use? Can components be repaired instead of replacing the whole robot? Does better warehouse awareness reduce damaged products, wasted trips, or unnecessary equipment usage? Is the software able to operate on any type of robot?*