Month: October 2026

This week, I focused on developing the software infrastructure design and expanding the project’s design report. My work translated our high-level architecture into a more detailed plan for connecting sensing, localization, mapping, navigation, and multi-robot communication. This included identifying existing software components we can reuse, specifying the interfaces between them, and identifying the features that still require project-specific implementation.

I researched and documented the software stack for the Raspberry Pi and ROS 2 environment. The proposed stack combines sensor drivers, a motor and encoder interface, robot_localization, SLAM Toolbox, and Nav2. I also compiled links to the relevant software repositories and documentation, identifying hardware-dependent gaps such as the final motor-controller interface and validation of the selected IMU driver.

A major part of this work was specifying how the components connect. I documented the expected sensor topics, filtered odometry, occupancy maps, and navigation actions.

My progress is currently slightly behind due to our delays in hardware component acquisition. Since we have defined the necessary components for the project, I believe that this delay should not affect my timeline, since linking together the components on actual hardware should be fairly straightforward. Next week I will test our proposed software on the actual hardware, since they should have arrived by then.

This week I made some key decisions regarding the physical robot implementation. Last week I wrestled with the dilemma that our original cheap Amazon robot chassis didn’t have proper encoder information. To determine next steps I weighed a lot of factors:

First, how necessary are encoders when we have an IMU? Quick search shows that encoder feedback data cannot be replaced by our 6DOF IMU units, and is very important to have long-run viable localization. Encoder data complemented by IMU data makes for the most accurate. Thus, I pursued encoder data further.

Secondly, how possible is it to jerry-rig optical sensors onto the bottom of the existing chassis? It’s cheap! 4-pack (one for each wheel) for $9 bucks on Amazon. But the footprint underneath the chassis is very small, and doesn’t allow for ample sensor room, additionally, there’s no where to mount them! I decided this solution is no easily replicable nor reliable, and this is important for the sake of SWARM since our goal is to have multiple identical robots at the end of the semester.

Lastly, we come to the option of buying a new chassis. What kit to get? Encoder motors and sufficient product specifications are necessary this time in order to make sure we don’t get misled by the advertising again. Between the two reliable suppliers that I found, HiWonder and Yahboom, they had high quality encoder motors, compatible motor drive boards, battery and battery charger kits, larger chassis footprint and mounting points, and much more security through documentation. The ultimate decision came down to drive train, where the Yahboom chassis had differential drive, vs. HiWonder’s Ackermann drive train. Ackermann drive train doesn’t enable turning in place, and we determined as a team that this was important for our 2D mapping use case, where a robot could find itself in a narrow corridor that it needs to get out from.

I updated the BOM with this new product, and returned a bunch of products that I bought for the old chassis to ECE Receiving.

Additionally, with the Design Document due date being this week, I spent the rest of my time towards this. Contributing writing to assorted sections in the doc, and creating new, more comprehensive hardware design visuals to add.

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?*

The most significant risk of hardware delays has already occurred, due to the chassis we bought not coming with any encoders, and not easily being able to be fitted with encoders. The encoders are needed for running SLAM. Because we worked our design to be under budget, we have enough room to tolerate these setbacks and are currently researching alternative robot chassis.
We have not made any new changes to the system design yet, and adjusted the first-robot-assembly timeline to reflect the setbacks and be more realistic.

This week I worked on setting up SLAM-toolbox in a local environment. I set up a docker container running Ubuntu 24.04 and ROS2 kilted, which are the versions used by the distributed SLAM toolbox demo. I have successfully gotten SLAM toolbox to build and run in the dev environment, but am still currently debugging issues with getting the demo to work as well.
My progress is currently ahead of schedule. Despite the debugging hold, understanding ROS2 and its capabilities has drastically simplified the initial design of the software infrastructure, which originally we dedicated an extra week to.
Next week, I hope to get the SLAM toolbox demo working properly, and develop an interface to implement our own additions to the library.

Ran into some obstacles while assembling the newly arrived parts and trying to test the chassis motors:

• the raspberry pis did not come with microSD cards. Thus we can’t yet run any OS on them nor use them to test the robot chassis
• the chassis kit contains encoder wheels, but no sensors that would return any useful data from the wheels… Thus, even if we could drive the car, we don’t have motor feedback which can be problematic for accurate driving.

Considering these obstacles, this week I accomplished:

• assembling the first chassis

• ordering microSD cards + adding to the team BOM
• change team Gantt chart to reflect new schedule due to set backs, specifically my task timeline
• created a working doc for my hardware-assembly specific tasks to make it easier to map next-steps in order to prevent set backs from unforeseen obstacles and keep track of my progress

To accomplish next week:

• comprehensive design plan that considers more thoroughly the end-to-end robot in order to prevent similar set backs in the next attempt at reassembly
• evaluate and order new chassis with actual encoder motors!