Lab

Recommended Tools

In addition to the resources that the course provides, students may find it useful to obtain the tools below:

  • wire cutter
  • wire stripper
  • needle nose pliers
  • screwdrivers
  • hex set (ball ends)
  • electrical tape
  • small scissors
  • a small file

Lab Resources

The Srivastava Senior Design Lab (2070 ECEB) is dedicated to ECE 445 usage. This lab provides you access to a vast array of lab equipment, hardware, and software for your use in developing and implementing your senior design project. In addition, course staff will make themselves available in this lab during their office hours to provide guidance on your project throughout the semester. It is our intention that this laboratory space provides you and your team with all the tools you would need to develop and test your project (within reason!). If there is something that you require in the lab to complete your project that does not exist in the lab, talk to your TA and we will see if we can remedy the situation.

Lab Bench Reservations

If and when the semester gets so busy that finding a lab bench to work at becomes difficult, please make use of the Lab Bench Reservation System in PACE. Reserving a lab bench will guarantee priority access to that bench, even when the lab is busy. To use the tool, after authenticating in PACE, you will see a page with a title "Signup for lab bench" with some text and a large table below that. The table shows the schedule for each bench on a given day (use the orange arrows or "Go To Date" text box to see a different day).  You make your reservation by simply clicking in a grid cell in the table, which will turn the box green. Click on it again to un-reserve the bench (and the box will turn white again).  Benches that are already reserved by another group will be denoted with a yellow box (you can hover your mouse over a yellow box to find out what group has reserved the bench).

A few ground rules:

  1. You may use a lab bench (a) during a time for which you have it reserved or (b) any time during which it is not reserved in the system (on a first-come-first-served basis). However, if you are working at a bench that is unreserved and somebody reserves it using the online system, the group with the reservation gets the lab bench.
  2. There is a limit on the amount of time for which you can reserve benches in 2070 ECEB.  The limit is currently a total of 4 hours of total bench time in the lab per group per day (e.g., 2 hours at Bench A and 2 hours at Bench B would max out your team's reservations for the day).  While this may seem restrictive, keep in mind that the course serves more than 60 groups in a typical semester and the lab has only 16 benches.  Also keep in mind that you can work at a bench if it is unreserved.
  3. Some lab benches have specialized equipment at them, such as digital logic analyzers.  Try to reserve the lab bench that has the equipment that you need.
  4. Cancel reservations that you will not need as soon as possible to give other groups a chance to reserve the lab bench.  You can cancel a reservation up to 1 hour before time and not have it count against your daily allotment.
  5. Conflicts and/or reports of people not following these rules should be sent to your TA with the course faculty in copy.
  6. Above all, be courteous.  Especially near the end of the semester, the lab will be full most of the time and stress will abound.  Clean up the lab bench when you are done with it.  Start and end your sessions on time.  Be patient and friendly to your peers and try to resolve conflicts professionally.  If we notice empty lab benches that have been reserved, we will cancel your reservations and limit your ability to reserve lab benches in the future. Similarly, do not reserve more time than you will need.  If we notice that you are frequently canceling reservations, we will limit your ability to reserve lab benches in the future. Finally, do not try to “game” the system and reserve a bench for 30 minutes every hour for eight hours. We will notice this and revoke your ability to reserve a bench.

Lab Rules

There are two overriding rules of working in the Srivastava Senior Design Lab. First, be safe. Second, be courteous. Lab access will be revoked if you fail to complete the required laboratory safety training by the deadline or if you break any of the lab rules. Specific points and examples of what we expect:

Breaking the rules or exhibiting bad laboratory etiquette will lead to a loss of points and/or revocation of laboratory access.

Lab Equipment Rules

Do not remove any equipment from the lab. Students may not change the connections on equipment without TA approval. Any approved changes that are made should be undone before leaving the lab. If a bench instrument is malfunctioning, a red repair tag should be placed on it and you should notify your TA. This alerts the staff to the problem, and allows the Electronics Services Shop to fix the problem.

When using a piece of laboratory equipment for the first time, please ask a TA for help. If you are inexperienced with a piece of hardware, do not assume that it is broken just because you cannot figure out how to use it. Similarly, if you use a piece of equipment to test your project and the equipment does not perform the way you think it should, do not assume the fault is with the equipment, and do not try again with equipment on another bench. Rather, stop and make absolutely sure the problem is not with your connections or project.

If you break any laboratory equipment, you must tell your TA within 1 business day. Any attempts to conceal breakage will result in an F in the course.

Room Access

The lab room (2070 ECEB) is on the electronic key-card system. The Department automatically adds room access to the building and the lab for all students on the roster. You will need a “prox enanabled” I-Card to swipe into the room. If the door does not open after several attempts, you may need to get a replacement card. Room access is automatically restricted to faculty and TAs during official breaks (i.e., Thanksgiving, Christmas, and Spring Break).

Computer Access

The lab computers are EWS computers and are setup like other Windows-based EWS systems you are familiar with. Standard EWS rules apply to these machines. In particular, please store any/all files you generate on a network drive or in the cloud. The C: drive should not be used for any personal material, since it is unprotected and is available only on the particular machine where it was originally stored. A particular computer may be cleared and reconfigured at any time for maintenance reasons.

In addition to the desktop computers, EWS maintains the printer in the lab. You are free to use it to print documents related to your project, but be aware that this printing counts against your standard print quota.

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.