Project

# Title Team Members TA Documents Sponsor
55 Heterogeneous Multi-Robot Cooperative Localization and Communication Testbed
Sahil Jain
XP Liu
Yuxiang Xing
Tim Jiang
Team Members:
- XP Liu (xpliu2)
- Yuxiang Xing (xing14)
- Sahil Jain (sahil5)

# Revision Summary

Following Professor Fliflet's September 10 feedback, our core deliverable is a one-leader, two-follower system based on AprilTags. Both followers B and C are required. We will prioritize simultaneous three-robot operation using one shared follower PCB design and software implementation. UWB, LiDAR, complex navigation, and sensor benchmarking remain optional. The numerical acceptance criteria below are proposed for course-staff review.

# Problem

Mobile robots working together need to estimate their relative position and heading, exchange task information, and follow a moving leader without contact. A small laboratory platform can demonstrate these functions in a repeatable environment.

We address a bounded version of this problem: two differential-drive followers independently estimate the pose of one tracked leader using AprilTags, follow it simultaneously at low speed, and stop at two distinct relative poses after the leader stops. The principal engineering work is a custom follower motor, power, and safety PCB, its embedded control firmware, and integration with onboard AprilTag localization and three-robot coordination.

# Solution

The required system consists of an existing tracked leader A and two followers B and C. Each follower will use a copy of the same custom PCB design and the same onboard software, with separate robot IDs, calibration values, and target offsets. Completing only A and B is an intermediate milestone, not the final demonstration.

Core tests use a flat 3 m x 3 m indoor field with controlled lighting and two obstacle-free marked routes, one straight and one gently curved, each approximately 1 m long. An operator guides A at no more than 0.10 m/s and slows on curves to keep both followers within their validated speed and camera-visibility limits. Autonomous route planning, narrow-aisle coordination, and arbitrary initial poses are not required.

Each follower directly observes an AprilTag target on A with its own onboard camera. Encoder measurements and an IMU support short-term motion estimation between visual updates; AprilTags are the primary relative-pose reference. Wi-Fi carries robot IDs, sequence numbers, heartbeat and task/health state. A does not need to provide an absolute map pose, and a laptop does not supply externally measured pose or wheel commands to B or C.

B and C occupy separate rear-left and rear-right positions relative to A. The initial proposed targets, expressed at defined robot reference points in A's frame (x forward, y left), are B: (-0.75 m, +0.30 m) and C: (-0.75 m, -0.30 m), both with A's heading. Before scored trials, the offsets and tag/camera mounting geometry will be checked against actual chassis dimensions, camera field of view, marker occlusion, route swept areas, and stopping clearance. Any necessary offset adjustment will be documented and fixed before scoring; error tolerances will not be changed between trials. The robots will not exchange sides or cross each other's approach paths.

Core trials start with both followers in their assigned regions, A's target visible to both cameras, and valid communication. Multiple rigidly mounted AprilTags with known transforms to A may be used to maintain both sight lines. Loss of visibility causes a stop rather than an attempt to recover from arbitrary poses. After A stops, B and C settle at their respective targets. This controlled arrangement demonstrates one leader with two simultaneous followers without adding general obstacle avoidance.

The custom PCB, firmware, control logic, and integration will be developed for this course. Existing chassis, A's controller, commercial sensor modules, and open-source libraries will be identified as reused components. No employer hardware, software, or proprietary dataset will be reused.

# System Operation

1. Place A, B, and C at surveyed starting poses in their assigned regions. Verify both AprilTag estimates, robot IDs, heartbeat reception, and local motor-disable operation.
2. Start a trial and guide A along one marked route within the validated speed and visibility envelope.
3. B and C independently estimate A's relative pose onboard, track their distinct target offsets, and send bounded wheel-speed requests to their own custom PCBs.
4. Each PCB acquires encoder feedback and runs local closed-loop wheel-speed control and a Pi-command watchdog.
5. After A stops, both followers settle at their assigned poses, limiting final-approach speed to 0.05 m/s.
6. A follower enters SAFE_STOP on invalid visual localization, stale required heartbeat/task messages, or a local Pi-command timeout. Each follower monitors the leader and the other follower's health; a reported peer fault or missing peer heartbeat also requests a stop. The operator stops A on a fault. Each follower's local stop must work without relying on the laptop or successful delivery of a fault message.
7. Recovery requires valid inputs and an explicit restart. Independent overhead/manual measurements are recorded for evaluation only.

# Solution Components

## Subsystem 1: Leader and Two Follower Platforms

- Leader A: existing personally owned tracked chassis and drive controller; exact model and available control interface remain to be documented.
- A additions: rigid AprilTag target assembly with measured dimensions and transforms, and a Wi-Fi heartbeat/task-state bridge. ESP32-S3-WROOM-1 is proposed for the bridge; its interface to the existing platform remains to be verified.
- Followers B and C: two identical ECE 110/SparkFun Shadow-style differential-drive chassis candidates, with encoder-equipped brushed DC gearmotors. Exact chassis and motor part numbers remain to be selected.
- Simple rigid camera/sensor mounts and distinct robot identification; no payload manipulation, rack structures, or interchangeable task fixtures are required.

## Subsystem 2: AprilTag Relative Localization

- One Raspberry Pi Global Shutter Camera with Sony IMX296 sensor per follower, proposed; lenses and mounting geometry to be selected for the working distance and both target positions.
- AprilTag targets on A with known transforms to its reference frame. Known floor markers may support calibration and initial checks.
- Quadrature wheel encoders and a BNO085 IMU per follower, proposed, for supporting motion estimates.

We will calibrate each camera-to-follower transform and each tag-to-leader transform. Each follower's relative-pose estimate will refer to defined robot reference points. Only one working AprilTag-based localization configuration is required. Encoder/IMU integration will remain lightweight; an extensive sensor-fusion comparison is not a core deliverable. UWB and LiDAR are not prerequisites for any core test.

## Subsystem 3: Onboard Control and Communication

Each follower will use a Raspberry Pi 5 (4 GB), proposed, for image processing, relative-pose estimation, and its state machine. ROS 2 and rosbag2 may be used for messages and logging. The shared states are IDLE, FOLLOW, RENDEZVOUS, SETTLE, COMPLETE, and SAFE_STOP. The implementation is reused on B and C, with individual calibration, IDs, and target offsets.

The controller generates bounded left/right wheel-speed requests with experimentally calibrated deadband compensation. Core follower speed is limited to 0.10 m/s. Formation offsets, curve speed, and initial regions will be chosen so simultaneous following does not require a follower to exceed this limit. Neither follower may steer through the other's assigned region to regain its target; invalid localization or a departure from the validated operating envelope ends the trial.

Wi-Fi messages contain robot ID, sequence number, and task/health state. Local receipt times detect stale data without requiring precise inter-robot clock synchronization. Each PCB has an independent watchdog for commands from its own Pi. A laptop starts trials and records results; all follower localization and wheel control run onboard.

## Subsystem 4: Shared Custom Follower Motor, Power, and Safety PCB

One custom PCB design, assembled and used on both B and C, is the main circuit-level deliverable. Each board integrates:

- ESP32-S3-WROOM-1 microcontroller, proposed, for encoder acquisition, wheel-speed control, and watchdog handling.
- Two brushed-DC motor-drive channels; TI DRV8876 is a candidate subject to operating/stall-current measurements and final circuit review.
- INA226 current/bus-voltage monitoring, proposed.
- Encoder input conditioning and appropriate protection.
- Battery input fuse, reverse-polarity protection, and regulated computer/logic power rails.
- Physical motor-disable/emergency-stop input and local command watchdog.
- A defined Pi-to-microcontroller command interface, sensor connectors, and debugging test points.

Motor, battery, and regulator part numbers remain pending load characterization. These selections and A's interface will be resolved before schematic finalization. Both board assemblies will be checked first with wheels lifted and then at restricted field speed. C reuses the validated design; it does not require a second independent circuit or software architecture.

## Subsystem 5: Test Field and Independent Evaluation

The flat 3 m x 3 m field contains a straight and a gentle curved route of approximately 1 m each. Both routes must preserve direct views of A's tags, separate follower approach regions, and physical clearance throughout motion and stopping. Core tests exclude narrow aisles, route replanning, moving obstacles, uneven surfaces, and deliberate prolonged visual occlusion.

An overhead camera with top-mounted fiducials records all three trajectories independently of the onboard cameras. Its exact model remains to be selected. Surveyed static positions and headings will validate calibration and measurement uncertainty. Final poses will also be checked using floor references and manual distance/angle measurements. We will not claim compliance where measurement uncertainty prevents distinguishing pass from fail.

Logs will report each follower's relative-pose and following errors, final position/heading errors, joint trial success, and communication/stop events. These measurements evaluate the robots and do not feed their controllers.

# Experimental Plan

1. Characterize follower motors/loads, finalize common components and A's interface, and validate the shared custom PCB and local stop functions.
2. Calibrate the AprilTag system and bring up A with B as an intermediate integration milestone.
3. Assemble C using the same design and software, calibrate it independently, and verify simultaneous visibility and safe distinct target positions. Allocate integration time for C before optional features.
4. Tune simultaneous B/C following on the straight route, then the gentle curve, followed by settling at their respective poses. Fix the tested offsets and geometry before scoring.
5. Run the scored three-robot trials and per-follower fault tests. Attempt optional extensions only after the full one-leader, two-follower system meets the core criteria.

# Criterion for Success

These are proposed acceptance criteria for staff review under the controlled conditions above. Both followers are required; single-follower success does not satisfy the final system criterion.

1. **AprilTag relative localization:** For each of B and C, evaluate ten surveyed static relative poses with A's tag visible, covering 0.5-1.0 m reference-point separation and relative heading within +/-30 degrees, including the selected formation geometry. Each follower shall estimate planar relative position within 5 cm and relative heading within 5 degrees at at least eight of its ten poses, measured against independent references.

2. **Simultaneous following and rendezvous:** The complete A+B+C system shall pass at least eight of ten joint trials, five on each marked route. A moves at no more than 0.10 m/s, reduced on curves as needed. After the first two seconds of motion, each follower shall have absolute reference-point separation error relative to its assigned target separation no greater than 15 cm in at least 80% of evaluated moving samples. Both followers must remain on their assigned sides with physical clearance; missing localization samples count as failures of the sample condition, not omitted data. Within 30 seconds after A stops, both followers shall settle at their distinct assigned relative poses with planar position error no greater than 5 cm and heading error no greater than 5 degrees, and remain stopped simultaneously for at least one second. A trial passes only if both followers satisfy all conditions in that same trial, with no collision or intervention on either follower. Aborted trials and trials where only one follower succeeds count as failures.

3. **Integrated hardware and safe stopping:** Both followers shall perform the motion tests using their own assembled copy of the custom PCB and onboard control. For each follower, independently test loss of required Wi-Fi heartbeat, loss of valid AprilTag localization, and loss of Pi-to-PCB commands. The affected follower shall come to rest within 0.5 seconds of its last valid relevant input at the maximum follower test speed of 0.10 m/s. Test each fault three times per follower; all must pass. Verify each physical motor-disable input disables drive actuation. Also verify the other follower stops on a reported peer fault or peer-heartbeat timeout. Perform fault tests with sufficient clearance and operator control of A; recovery requires valid inputs and an explicit restart.

# Optional Extensions

Only after A, B, and C pass the core criteria:

- Evaluate Qorvo DWM3001CDK UWB boards as auxiliary ranging.
- Add LiDAR or short-range ToF sensing, or compare additional localization configurations.
- Explore changed lighting, partial occlusion, additional initial poses, or simple obstacle layouts.
- Improve stationary rendezvous precision toward 2 cm and 3 degrees.

The required deliverable is one existing leader and two custom-controlled followers demonstrating simultaneous AprilTag-based localization, low-speed following, settling at separate relative poses, and local fail-safe stopping.

Oxygen Delivery Robot

Aidan Dunican, Nazar Kalyniouk, Rutvik Sayankar

Oxygen Delivery Robot

Featured Project

# Oxygen Delivery Robot

Team Members:

- Rutvik Sayankar (rutviks2)

- Aidan Dunican (dunican2)

- Nazar Kalyniouk (nazark2)

# Problem

Children's interstitial and diffuse lung disease (ChILD) is a collection of diseases or disorders. These diseases cause a thickening of the interstitium (the tissue that extends throughout the lungs) due to scarring, inflammation, or fluid buildup. This eventually affects a patient’s ability to breathe and distribute enough oxygen to the blood.

Numerous children experience the impact of this situation, requiring supplemental oxygen for their daily activities. It hampers the mobility and freedom of young infants, diminishing their growth and confidence. Moreover, parents face an increased burden, not only caring for their child but also having to be directly involved in managing the oxygen tank as their child moves around.

# Solution

Given the absence of relevant solutions in the current market, our project aims to ease the challenges faced by parents and provide the freedom for young children to explore their surroundings. As a proof of concept for an affordable solution, we propose a three-wheeled omnidirectional mobile robot capable of supporting filled oxygen tanks in the size range of M-2 to M-9, weighing 1 - 6kg (2.2 - 13.2 lbs) respectively (when full). Due to time constraints in the class and the objective to demonstrate the feasibility of a low-cost device, we plan to construct a robot at a ~50% scale of the proposed solution. Consequently, our robot will handle simulated weights/tanks with weights ranging from 0.5 - 3 kg (1.1 - 6.6 lbs).

The robot will have a three-wheeled omni-wheel drive train, incorporating two localization subsystems to ensure redundancy and enhance child safety. The first subsystem focuses on the drivetrain and chassis of the robot, while the second subsystem utilizes ultra-wideband (UWB) transceivers for triangulating the child's location relative to the robot in indoor environments. As for the final subsystem, we intend to use a camera connected to a Raspberry Pi and leverage OpenCV to improve directional accuracy in tracking the child.

As part of the design, we intend to create a PCB in the form of a Raspberry Pi hat, facilitating convenient access to information generated by our computer vision system. The PCB will incorporate essential components for motor control, with an STM microcontroller serving as the project's central processing unit. This microcontroller will manage the drivetrain, analyze UWB localization data, and execute corresponding actions based on the information obtained.

# Solution Components

## Subsystem 1: Drivetrain and Chassis

This subsystem encompasses the drive train for the 3 omni-wheel robot, featuring the use of 3 H-Bridges (L298N - each IC has two H-bridges therefore we plan to incorporate all the hardware such that we may switch to a 4 omni-wheel based drive train if need be) and 3 AndyMark 245 RPM 12V Gearmotors equipped with 2 Channel Encoders. The microcontroller will control the H-bridges. The 3 omni-wheel drive system facilitates zero-degree turning, simplifying the robot's design and reducing costs by minimizing the number of wheels. An omni-wheel is characterized by outer rollers that spin freely about axes in the plane of the wheel, enabling sideways sliding while the wheel propels forward or backward without slip. Alongside the drivetrain, the chassis will incorporate 3 HC-SR04 Ultrasonic sensors (or three bumper-style limit switches - like a Roomba), providing a redundant system to detect potential obstacles in the robot's path.

## Subsystem 2: UWB Localization

This subsystem suggests implementing a module based on the DW1000 Ultra-Wideband (UWB) transceiver IC, similar to the technology found in Apple AirTags. We opt for UWB over Bluetooth due to its significantly superior accuracy, attributed to UWB's precise distance-based approach using time-of-flight (ToF) rather than meer signal strength as in Bluetooth.

This project will require three transceiver ICs, with two acting as "anchors" fixed on the robot. The distance to the third transceiver (referred to as the "tag") will always be calculated relative to the anchors. With the transceivers we are currently considering, at full transmit power, they have to be at least 18" apart to report the range. At minimum power, they work when they are at least 10 inches. For the "tag," we plan to create a compact PCB containing the transceiver, a small coin battery, and other essential components to ensure proper transceiver operation. This device can be attached to a child's shirt using Velcro.

## Subsystem 3: Computer Vision

This subsystem involves using the OpenCV library on a Raspberry Pi equipped with a camera. By employing pre-trained models, we aim to enhance the reliability and directional accuracy of tracking a young child. The plan is to perform all camera-related processing on the Raspberry Pi and subsequently translate the information into a directional command for the robot if necessary. Given that most common STM chips feature I2C buses, we plan to communicate between the Raspberry Pi and our microcontroller through this bus.

## Division of Work:

Given that we already have a 3 omni wheel robot, it is a little bit smaller than our 50% scale but it allows us to immediately begin work on UWB localization and computer vision until a new iteration can be made. Simultaneously, we'll reconfigure the drive train to ensure compatibility with the additional systems we plan to implement, and the ability to move the desired weight. To streamline the process, we'll allocate specific tasks to individual group members – one focusing on UWB, another on Computer Vision, and the third on the drivetrain. This division of work will allow parallel progress on the different aspects of the project.

# Criterion For Success

Omni-wheel drivetrain that can drive in a specified direction.

Close-range object detection system working (can detect objects inside the path of travel).

UWB Localization down to an accuracy of < 1m.

## Current considerations

We are currently in discussion with Greg at the machine shop about switching to a four-wheeled omni-wheel drivetrain due to the increased weight capacity and integrity of the chassis. To address the safety concerns of this particular project, we are planning to implement the following safety measures:

- Limit robot max speed to <5 MPH

- Using Empty Tanks/ simulated weights. At NO point ever will we be working with compressed oxygen. Our goal is just to prove that we can build a robot that can follow a small human.

- We are planning to work extensively to design the base of the robot to be bottom-heavy & wide to prevent the tipping hazard.