Project

# Title Team Members TA Documents Sponsor
5 Navigation Vest Suite For People With Eye Disability
Haoming Mei
Jiwoong Jung
Pump Vanichjakvong
Rishik Sathua design_document1.pdf
final_paper1.pdf
photo1.png
photo2.JPG
proposal1.pdf
video
# Navigation Vest Suite For People With Eye Disability


Team Members & Experiences:
- Jiwoong Jung (jiwoong3): Experienced in Machine Learning, and some Embedded programming. Worked on many research and internships that requires expertise in Machine Learning, Software Engineering, Web Dev., and App Dev. Had some experience with Embedded programming for Telemetry.
- Haoming Mei (hmei7): Experienced in Embedded programming and PCB design. Worked with projects like lights, accelerometer, power converter, High-Fet Board, and motor control for a RSO that involve understanding of electronics, PCB design, and programming with STM32 MCUs.
- Pump Vanichjakvong (nv22): Experienced with Cloud, Machine Learning, and Embedded programming. Done various internships and classes that focuses on AI, ML, and Cloud. Experience with Telemetry and GPS system from RSO that requires expertises in SPI, UART, GPIOs, and etc with STM32 MCUs.

# Problem

People with Eye Disability often face significant challenges navigating around in their daily lives. Currently, most available solutions ranges like white canes and guide dogs to AI-powered smart glasses, many of which are difficult to use and can cost as much as $3,000. Additionally, problems arises for people with disability, especially in crowded/urban areas, and that includes injuries from collision with obstacles, person, or from terrains. According to the U.S department of Transportation's 2021 Crash Report , 75% of pedestrian fatalities occurred at locations that were not intersections. Thus we aim to design a navigation vest suite to help people with eye disability to deal with these issues.

https://crashstats.nhtsa.dot.gov/Api/Public/ViewPublication/813458.pdf

# Solution
We have devised a solution which helps ease visually impaired individuals in daily activities such as walking from two places, or navigating around a building with multiple obstacles. Our focus will for out-door navigation in urban areas, where obstacles, terrain, and pedestrians. But, if time permits we will also deal with traffics and crosswalks.




In order to achieve this, we will be utilizing 3 main components:
- Lidar sensors to help the wearer with depth perception tasks
- Vibration Motors to aid navigation (turning left/right)
- Magnetometer to enable more accurate GPS coordination

All the above components will contribute to the sensory fusion algorithm.

# Solution Components

## Subsystem 1
### Microcontroller System
We are planning to use a STM32 microcontroller as main processing unit for sensory data from lidar sensors (magnetometer and GPS if time permits) and object detection data from the **machine learning system**, and direction data from navigation app (our design on phone). We will use these information to generate vibration in the direction the wearer should navigate.

### Power Systems
The whole system will be battery-powered by a battery module, which contains 5V battery-cells. It will be connected to the **Microcontroller System**, which will also supply it to the **Machine Learning System**. We will also implement the necessary power protection, buck converter, regulator, and boost converters as necessary per sensors or components.
- Battery Module Pack
- Buck Converter (Step-Down)
- Boost Converter (Step-Up)
- Voltage Regulator
- Reverse Polarity Protection
- BMS

## Subsystem 2
### Navigation Locator Systems
Our navigation system will consist of an App which directly connects to the Google Maps API, paired with our existing sensors. We plan to utilize a magnetometer sensor, which will indicate the direction the user is facing (North, South, East, West, .etc). In order to pinpoint which direction the wearer needs to be heading, our built-in LiDAR sensors will enable us to create a SLAM (Simultaneous Localization and Mapping) to build a map of the environment. With these systems in place, we would be able to assist users in navigation. To deal with Terrain hazards, we will use the LiDAR to sensors to assist us in dealing with elevation changes the user needed to make.

- LiDAR
- Android App (Connected to Google API)
- Magnetometer
- Vibration Motors

Extra Features (if time permits):
- Audio Output (Text to Speech Generation from Raspberry PI 5 sends to microcontroller through AUX cable )
## Subsystem 3
### Machine Learning Systems

- We plan to employ a object detection model on a 16GB Raspberry PI 5 (already) along with a PI camera to detect objects, signs, and people on the road, which will be feed to the microcontroller
- Raspberry PI 5
- PI Camera


a) The image video model will be expected to be less than 5 billion parameters with convolutional layers, running on device in raspberry pi Obviously the processing power on the raspberry pi is expected to be limited, however we are planning to accept the challenge and find out ways to improve the model with limited hardware capabilities.

b) If the overall project for subtask a) becomes arduous or time consuming, we can utilize api calls or free open source models to process the image/video in real time if the user wants the feature enabled. The device is paired with the phone via the wifi chip on the raspberry pi to enable the API call. Some of the best candidates we can think of are the YOLO family models, MMDetection and MMTracking toolkit, or Detectron2 model that is developed by Facebook AI Research that supports real time camera feedbacks.

# Criterion For Success


### Navigational Motor/Haptic Feedback
1) The Haptic feedback (left/right vibration) should perfectly match with the navigation directions received from the app (turn left/right)

2) Being able to Detect Obstacles, Stairs, Curbs, and people.

3) Being able to detect intersections infront and the point of turn through the lidar sensory data.

4) Being able to obey the haptic feedback patterns that is designed. (tap front for walking forward, tap right to go right etc...)

### Object Detection
1) Using the Illinois Rules of the Road and the Federal Manual on Uniform Traffic Control Device Guidelines, we will be using total of 10-30 distinct pedestrian road signs to test the object detection capability. We will be using a formal ML testing methods like geometric transformations, photometric transformations, and background clutter. Accuracy will be measured by the general equation (Total Number of correctly classified Datasets)/(Total Number of Datasets)

2) The ML Model should be able to detect potential environmental hazards including but not limited to Obstacles, Stairs, Curbs, and people. We are planning onto gather multiple hazard senarios via online research, surveys, and in-person interviews. Based on the collected research, we will be building solid test cases to ensure that our device can reliably identify potential hazards. More importantly, we are planning design strict timing and accuracy measures metrics.


3) The ML model should be able to detect additional road structures such as curbs, crosswalks, and stairs to provide comprehensive environment awareness. We will be utilizing different crosswalks located on north quad and utilize the accuracy measurement techniques mentioned in 1)



### Power and Battery Life

1) The device should support at least 3 hours of battery life.

2) The device should obey the IEC 62368-1 safety standard. IEC 62368-1 safety standard lays out different classes such as ES1, ES2, and ES3 that considers electrical and flame



ATTITUDE DETERMINATION AND CONTROL MODULE FOR UIUC NANOSATELLITES

Shamith Achanta, Rick Eason, Srikar Nalamalapu

Featured Project

Team Members:

- Rick Eason (reason2)

- Srikar Nalamalapu (svn3)

- Shamith Achanta (shamith2)

# Problem

The Aerospace Engineering department's Laboratory for Advanced Space Systems at Illinois (LASSI) develops nanosatellites for the University of Illinois. Their next-generation satellite architecture is currently in development, however the core bus does not contain an Attitude Determination and Control (ADCS) system.

In order for an ADCS system to be useful to LASSI, the system must be compliant with their modular spacecraft bus architecture.

# Solution

Design, build, and test an IlliniSat-0 spec compliant ADCS module. This requires being able to:

- Sense and process the Earth's weak magnetic field as it passes through the module.

- Sense and process the spacecraft body's <30 dps rotation rate.

- Execute control algorithms to command magnetorquer coil current drivers.

- Drive current through magnetorquer coils.

As well as being compliant to LASSI specification for:

- Mechanical design.

- Electrical power interfaces.

- Serial data interfaces.

- Material properties.

- Serial communications protocol.

# Solution Components

## Sensing

Using the Rohm BM1422AGMV 3-axis magnetometer we can accurately sense 0.042 microTesla per LSB, which gives very good overhead for sensing Earth's field. Furthermore, this sensor is designed for use in wearable electronics as a compass, so it also contains programable low-pass filters. This will reduce MCU processing load.

Using the Bosch BMI270 3-axis gyroscope we can accurately sense rotation rate at between ~16 and ~260 LSB per dps, which gives very good overhead to sense low-rate rotation of the spacecraft body. This sensor also contains a programable low-pass filter, which will help reduce MCU processing load.

Both sensors will communicate over I2C to the MCU.

## Serial Communications

The LASSI spec for this module requires the inclusion of the following serial communications processes:

- CAN-FD

- RS422

- Differential I2C

The CAN-FD interface is provided from the STM-32 MCU through a SN65HVD234-Q1 transceiver. It supports all CAN speeds and is used on all other devices on the CAN bus, providing increased reliability.

The RS422 interface is provided through GPIO from the STM-32 MCU and uses the TI THVD1451 transceiver. RS422 is a twisted-pair differential serial interface that provides high noise rejection and high data rates.

The Differential I2C is provided by a specialized transceiver from NXP, which allows I2C to be used reliably in high-noise and board-to-board situations. The device is the PCA9615.

I2C between the sensors and the MCU is provided by the GPIO on the MCU and does not require a transceiver.

## MCU

The MCU will be an STM32L552, exact variant and package is TBD due to parts availability. This MCU provides significant processing power, good GPIO, and excellent build and development tools. Firmware will be written in either C or Rust, depending on some initial testing.

We have access to debugging and flashing tools that are compatible with this MCU.

## Magnetics Coils and Constant Current Drivers

We are going to wind our own copper wire around coil mandrels to produce magnetorquers that are useful geometries for the device. A 3d printed mandrel will be designed and produced for each of the three coils. We do not believe this to be a significant risk of project failure because the geometries involved are extremely simple and the coil does not need to be extremely precise. Mounting of the coils to the board will be handled by 3d printed clips that we will design. The coils will be soldered into the board through plated through-holes.

Driving the inductors will be the MAX8560 500mA buck converter. This converter allows the MCU to toggle the activity of the individual coils separately through GPIO pins, as well as good soft-start characteristics for the large current draw of the coils.

## Board Design

This project requires significant work in the board layout phase. A 4-layer PCB is anticipated and due to LASSI compliance requirements the board outline, mounting hole placement, part keep-out zones, and a large stack-through connector (Samtec ERM/F-8) are already defined.

Unless constrained by part availability or required for other reasons, all parts will be SMD and will be selected for minimum footprint area.

# Criterion For Success

Success for our project will be broken into several parts:

- Electronics

- Firmware

- Compatibility

Compatibility success is the easiest to test. The device must be compatible with LASSI specifications for IlliniSat-0 modules. This is verifiable through mechanical measurement, board design review, and integration with other test articles.

Firmware success will be determined by meeting the following criteria:

- The capability to initialize, configure, and read accurate data from the IMU sensors. This is a test of I2C interfacing and will be tested using external test equipment in the LASSI lab. (We have approval to use and access to this equipment)

- The capability to control the output states of the magnetorquer coils. This is a test of GPIO interfacing in firmware.

- The capability to move through different control modes, including: IDLE, FAULT, DETUMBLE, SLEW, and TEST. This will be validated through debugger interfacing, as there is no visual indication system on this device to reduce power waste.

- The capability to self-test and to identify faults. This will be validated through debugger interfacing, as there is no visual indication system on this device to reduce power waste.

- The capability to communicate to other modules on the bus over CAN or RS422 using LASSI-compatible serial protocols. This will be validated through the use of external test equipment designed for IlliniSat-0 module testing.

**Note:** the development of the actual detumble and pointing algorithms that will be used in orbital flight fall outside the reasonable scope of electrical engineering as a field. We are explicitly designing this system such that an aerospace engineering team can develop control algorithms and drop them into our firmware stack for use.

Electronics success will be determined through the successful operation of the other criteria, if the board layout is faulty or a part was poorly selected, the system will not work as intended and will fail other tests. Electronics success will also be validated by measuring the current consumption of the device when operating. The device is required not to exceed 2 amps of total current draw from its dedicated power rail at 3.3 volts. This can be verified by observing the benchtop power supply used to run the device in the lab.