Project

# Title Team Members TA Documents Sponsor
45 PulseGuard: Hardware Encoder Integrity Monitor
 Chinmay Naveen
Sanjiv Kondin
 Alex Lee
* Sanjiv Kondin (skond32)
* Chinmay Naveen (cnaveen2)
*third student

Problem

Wheel encoders are commonly used by robots to measure how fast their wheels are turning and how far the robot has moved. If an encoder signal becomes corrupted, such as from missing pulses, extra pulses, or a disconnected signal, the robot may continue using incorrect measurements without knowing there is a problem.

We propose PulseGuard, a system that checks whether the encoder measurements are reliable by comparing them with an independent measurement from an IMU. The system will intentionally create encoder faults during testing and determine whether PulseGuard can detect the difference between the encoder and IMU measurements.

Solution

We will design and build a system that connects two wheel encoders, an IMU, and a microcontroller. The microcontroller will read the encoder signals and calculate the robot's turning speed. It will then compare this value with the turning speed measured by the IMU.

If the difference between the two measurements becomes larger than a selected threshold for a certain amount of time, the system will report that the encoder may have a fault.

The system will also include a simple fault-injection circuit that allows us to create different encoder problems during testing. This will allow us to test whether PulseGuard can detect real encoder faults in a controlled and repeatable way.

The design breaks down into four subsystems: encoder interface, fault injection, IMU sensing, and firmware.

Solution Components
Encoder Interface

The system will connect two wheel encoders to the microcontroller. The encoders will provide signals that show how fast each wheel is turning.

The encoder signals will be cleaned up using a Schmitt-trigger circuit before being sent to the microcontroller. This will help make sure the microcontroller receives clear digital signals.

Both encoder channels will be used so that the system can determine wheel movement and direction.

Part numbers (subject to change):

74HC14 Schmitt-trigger inverter
Resistors
Capacitors
Encoder connectors
Fault Injection

The system will include a simple circuit that allows us to intentionally change one encoder signal during testing.

Three types of faults will be tested:

Missing pulses
Extra pulses
Interrupted signal

A switch will be used to choose between the normal encoder signal and the modified signal.

The microcontroller will control when the fault is added so that the exact time of the fault can be recorded.

Part numbers (subject to change):

74HC4053 analog switch
74HC14 Schmitt-trigger inverter
Resistors
Capacitors
IMU and Fault Detection

A BNO085 IMU will be used to measure the robot's turning speed using its gyroscope.

The microcontroller will calculate the turning speed using the two encoder measurements and compare it with the turning speed measured by the IMU.

If the two measurements are different by more than a selected amount, the system will consider the encoder measurement unreliable.

A small delay will be used before reporting a fault so that normal sensor noise does not cause false alarms.

Part numbers (subject to change):

BNO085 IMU
I2C connections
Supporting capacitors
Firmware and Data Logging

The microcontroller will handle the encoder signals, IMU data, fault injection, and fault detection.

During testing, the system will record:

Encoder measurements
IMU measurements
Fault type
Fault injection time
Fault detection time
Fault status

The data will be sent to a computer through USB serial so that the results can be reviewed after testing.

Criterion For Success
High-level goals
Detect at least 90% of the encoder faults that are intentionally created.
Detect an encoder fault within 500 ms.
Keep the false-positive rate below 5% during normal operation.
Detect all three tested fault types:
Missing encoder pulses
Extra encoder pulses
Interrupted encoder signal
Correctly compare encoder and IMU measurements.
Record the time when a fault is created and detected.
Successfully send test data to a computer.
Testing/Demo

The system will first be tested without any faults to make sure the encoder and IMU measurements agree during normal operation.

The encoder signals will then be tested using an oscilloscope to make sure the system is receiving clean signals.

Each of the three fault types will be injected separately. At least 10 tests will be performed for each fault type.

During testing, the system will record the encoder measurement, IMU measurement, fault type, and detection time.

The system will also be tested during different types of motion, including:

Straight-line motion
Turning
Stopping and starting

The detection time will be calculated by comparing the time the fault was created with the time PulseGuard detected it.

Normal operation without injected faults will also be tested to determine the false-positive rate.

For the final demonstration, the robot will operate normally while PulseGuard monitors the encoder measurements. A controlled encoder fault will then be introduced. PulseGuard should detect the disagreement between the encoder and IMU and report an encoder fault.

The final results will demonstrate the system's ability to detect encoder faults, measure detection time, and avoid reporting faults during normal operation.

Smart Frisbee

Ryan Moser, Blake Yerkes, James Younce

Smart Frisbee

Featured Project

The idea of this project would be to improve upon the 395 project ‘Smart Frisbee’ done by a group that included James Younce. The improvements would be to create a wristband with low power / short range RF capabilities that would be able to transmit a user ID to the frisbee, allowing the frisbee to know what player is holding it. Furthermore, the PCB from the 395 course would be used as a point of reference, but significantly redesigned in order to introduce the transceiver, a high accuracy GPS module, and any other parts that could be modified to decrease power consumption. The frisbee’s current sensors are a GPS module, and an MPU 6050, which houses an accelerometer and gyroscope.

The software of the system on the frisbee would be redesigned and optimized to record various statistics as well as improve gameplay tracking features for teams and individual players. These statistics could be player specific events such as the number of throws, number of catches, longest throw, fastest throw, most goals, etc.

The new hardware would improve the frisbee’s ability to properly moderate gameplay and improve “housekeeping”, such as ensuring that an interception by the other team in the end zone would not be counted as a score. Further improvements would be seen on the software side, as the frisbee in it’s current iteration will score as long as the frisbee was thrown over the endzone, and the only way to eliminate false goals is to press a button within a 10 second window after the goal.