This week, on the robot-hardware side of things, the team fleshed out a wiring plan for the bot and ordered all associated components to be assembled next week.
Again, the most significant risk is a hardware defect or delay, which would push back all of our integration and on-robot development work. Our plan is still to leave enough budget and time in the event of any hardware issues.
We changed the design to use SLAM-toolbox instead of DOOR-SLAM. This was because DOOR-SLAM uses camera input, which is not compatible with our LiDAR-only design. Additionally, SLAM-toolbox has been designed with distributed fault tolerance in mind, is natively ROS2 + LiDAR, and has a built-in simulator for tests when hardware is not available.
A was written by Zhuoyi Zou, B was written by Rachel Lewis and C was written by Kevin Huang.
Part A:
SWARM is intended to help warehouse staff identify blocked aisles and shifted obstacles by comparing the robots’ updated map with the expected layout. An alert would direct staff to a specific location so they can assess and clear a hazard, or identify security issues preemptively, which would help keep routes accessible for safe worker and goods movement. We will test obstacle detection and alert accuracy before claiming that the system reliably identifies hazards.
The robots could themselves create a collision hazard when operating near people. Our safety design will limit robot speed during testing, stop motion when an obstacle is detected or required sensor data becomes unavailable, and provide a human-operated way to cut motor power. We will verify stopping behavior and sensor-failure responses during our development and testing.
Part B: For our obstacle-alerting system that is built on top of the 2D mapping data we receive from our robot SWARM, we are imagining a very clean and simple UI that is universal in understanding across diverse users. This is our main social factor consideration, to ensure that our final product is actually usable in the real world, to folks without an engineering or software or robotics background.
Ultimately, the goal of our technology is to promote warehouse operations to work as smoothly as possible, and this by nature doesn’t touch many of the realms of social considerations, like politics or culture. That being said, a connection could be made between providing the most accurate up-to-date data and improving the collaboration, culture, and social atmosphere of the warehouse working environment. Bringing real-time, reliable notifications of obstructions and potential discrepancies on the warehouse floor could surpass the office politics of word-of-mouth telephone, seeking approval/intervention from different departments, or worker-by-worker opinions/arguments about what-should-be-where-and-why. With the source-map underlying our technology, and the live mapping on top, obstacle detection is simple, accurate, and can be alerted to the folks in charge right away.
Part C:
For economic factors, we focused on keeping SWARM relatively low-cost and scalable by using cheap, commercially available components such as Raspberry PIs, LiDAR sensors, and publicly available robot chassis (instead of using specialized industrial hardware). This makes it easier to add additional robots to the system without requiring expensive hardware or centralized compute infrastructure. Since each robot is designed as a standalone unit that can do mapping and computation by itself, the system can continue operating if an individual robot fails, which makes failures much more economical than if there was a single expensive central point of failure.
In a warehouse, the economic benefit comes from reducing the amount of manual effort and time required to inspect and update warehouse layouts, and from identifying misplaced inventory or blocked paths more quickly. Using multiple robots helps reduce mapping time, which could streamline and reduce downtimes in warehouse operations. On the other hand, adding robots increases the hardware, maintenance, and replacement costs, so adding more robots only makes sense if they provide a significant improvement in mapping time and coverage.
We also considered repair and replacement costs when we selected components. Our design uses modular and replaceable parts, and we leave room in the project budget for duplicate robots and replacement components, which further reduces the impact of individual hardware failures.
