Project

# Title Team Members TA Documents Sponsor
79 Universal Gesture Interface
Connor Michalec
Kenobi Carpenter
Kobe Duda
Lukas Dumasius proposal1.pdf
# Universal Gesture Interface

Team members:
- Kenobi Carpenter (joseph48)
- Kobe Duda (ksduda2)
- Connor Michalec (connor15)
# Problem

Since the invention of the personal computer, the interface between humans and computers has remained relatively unchanged. The keyboard and mouse layout has proven highly effective for the majority of use cases, but its mostly-discrete nature greatly restricts the possible ways humans can interact with computer applications.

Much of the way we interact with the world requires expressive, free-flowing modes of interaction. Activities like playing an instrument, martial arts, dancing, or sculpting often can’t simply be described by a series of inputs in the correct order at the correct time. They take place in continuous, 3D space—yet, the most complex expression we typically get with a computer is the 2D plane that a mouse movement provides.

Some solutions exist to address this need, the most notable of these being VR headsets. However, these headsets tend to be expensive, large, and lead to feelings of fatigue and nausea for many users. As it currently stands, there is no low-cost, low-fatigue, desk-friendly input device that allows continuous spatial interaction on PC. Such a device would open new possibilities for how users interface with programs while also improving accessibility for those lacking in fine motor skills, i.e. limited finger dexterity.
# Solution

We propose a wearable gesture-detecting glove that allows users to interface with computer applications through hand and finger motions. This glove will have a wired USB connection (though wireless would be ideal, we are omitting it for the sake of scope) with two interfaces. The first interface is an HID compliant mouse, allowing the glove to be generally used for regular applications, while the second interface streams live 3D movement data to be interpreted by specialized applications. This dual-interface approach allows the glove to stand on its own as a general-purpose tool while also granting the extensibility to be leveraged to its full potential by specialized applications.

The sensor layout will consist of a 9-DOF IMU placed on the back of the hand for broad movements, three flex sensors in the index, middle finger, and thumb, and three force-sensitive resistors (FSRs) on the fingertips to detect touch.

Finally, the device will feature on-board DSP on the MCU. It will process raw sensor data and interpret a predefined set of gestures, then send those interpreted actions as discrete inputs to the target USB device.
# Solution Components

## Subsystem 1: IMU Unit

Components: ICM-20948

This 9-axis accelerometer will be used for detecting broad-phase translational and rotational movements of the hand. It will be mounted to the back of the palm, and raw sensor data will be sent over SPI to the MCU for processing.
## Subsystem 2: Flex sensors

Components: Adafruit Industries Short Flex/Bend Sensor

We will mount three flex sensors to the thumb, index finger, and middle finger. They will be connected each to an ADC port by voltage divider with a 50kOhm resistor. 0.1uF capacitors will be used for noise reduction. Used for detecting specific hand positions.
## Subsystem 3: Touch sensors

Components: Geekcreit FSR402 Force Sensitive Resistor

Three force-sensitive resistors will be attached to the tips of the thumb, index finger, and middle finger. Similar to the flex sensors, they will be wired to ADCs with voltage dividers (22kOhm) to be read by the MCU. Used for detecting pinching, tapping, and pressing.
## Subsystem 4: Microprocessor

Components STM32F405 Microprocessor

This microprocessor takes as input all of the aforementioned sensor data and sends USB as output. The processor itself has been chosen for its DSP capabilities, as processing sensor inputs and identifying them as gestures will constitute a considerable portion of this project. Attached to the PCB will be a USB port for connecting to a computer, over which identified gestures are sent as inputs to the computer.

This is also where most of our design decisions will be integrated. For example, the IMU is prone to drift, meaning we’ll have to make UX decisions that mitigate its influence, i.e. only moving the mouse when a finger is down on the desk.
## Subsystem 5: Physical Frame

Another important aspect of the project will be the physical design itself. In order for our project to be even moderately successful, it has to be wearable. This presents the unique challenge of designing a glove that is both comfortable and can house the electronic components in a way that does not impede movement.
## Subsystem 6: Associated Software

This is not a part of the actual project, but a testbed to demonstrate its capabilities. We will use Unreal Engine 5 to create a very basic flight simulation that allows for controlling the plane with orientation of the user’s hand.

For basic testing, we will also have a barebones program that receives gesture inputs and prints them to the screen when received over serial.
# Criterion for success
- Hand movements are able to reliably move a mouse on the attached device
- The following gestures/actions can be reliably detected and mirrored to test program
- Hand closed
- Hand open
- Light tap (index/middle/thumb)
- Firm press (index/middle/thumb)
- Pinching fingers (index-thumb, middle-thumb)
- Thumbs up
- Thumbs down
- User can successfully navigate a plane in the testbed program through a basic course using hand orientation

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.