ECE 110/120 Honors Lab Section : Self-Balancing Unicycle

Name	NetID	Section
Kunal Sheth	kunal4	ECE 110

Statement of Purpose

Please provide a brief description of your project. List the goals and objectives of your project and explain why this project is useful for the problem your group want to solve or functions that make your project unique.

This project is about creating an autonomous, single-wheeled, self-balancing robot capable of gracefully driving in any arbitrary path. My goals, in chronological order, include:

Controlling front-to-back angle via drive wheel.
Controlling side-to-side angle via reaction wheel.
Calculating desired front-to-back angle, side-to-side angle, and drive wheel omega in order to turn in some given curvature.
Recovering from reaction wheel saturation via drive wheel omega (generating centrifugal force to upright system).
Dead reckoning position to an accuracy of ~1" per yard traveled.
Motion profiling to drive in some given path without spilling a glass of water.

Background Research

Please provide details on the background research your group has done for your project. Explain what drives you to work on this project and/or why this project is important. Also include discussions on any similar projects your group have looked at in coming up with your project. How is your proposed project different or similar to those your group have looked at.

So far I've researched the classic "inverted pendulum on a cart" control problem, "reaction wheel inverted pendulum" systems, and the concepts of camber thrust / counter steering. These concepts are the foundations for how I plan to control the self-balancing unicycle. I will continue researching further into state-space representations and LQR control.

I've also been researching gyro-accelerometer sensor fusion techniques. However, I may instead opt for a COTS hardware-software solution as these tend to include more advanced drift compensation for factors like temperature. I don't want to spend too much time researching inertial measurement as I feel it is outside the scope of my project.

Block Diagram / Flow Chart

Electronics:

Software:

System Overview

Electronics:

Battery	12V, 60W, 10AH Li-ion battery connects to circuit via barrel connector. All circuit current flows through 4A resettable fuse. V_Battery line connects to voltmeter readout (not pictured), ESCs, and 5V step-down regulator (not pictured). V_Battery line also connects to microcontroller via ~2/5 voltage divider for battery voltage compensation in software.
ATmega32U4 MCU	Currently using 8-bit AVR microcontroller because of mistake in circuit design. Despite requiring 5V power and having 5V literally printed on the silkscreen, ARM Cortex board was in fact not 5V tolerant. ATmega32U4 is a temporary 5V tolerant substitute.
LCD	Readout for easier debugging and user feedback. Displays IMU calibration status, sensor readings, and motor outputs. Updated via 4800 baud Serial connection. Screen refreshed at 4Hz.
BNO085 IMU	Accelerometer, Gyroscope, and Magnetometer with on-board sensor fusion, automatic recalibration, and high-frequency gyroscope integration. Interrupts MCU at ~1kHz when new data is ready.
ESC	12V 5A BDC motor driver with simple PWM+DIR interface. Configured to be in “break mode” for more linear motor control.
Current Sensor	±5A current sensor with analog interface. Used for limiting or controlling current/torque applied to motors.
Motor/Encoder	Brushed DC motor with built-in 10:1 or 6.3:1 gearbox and 64 CPR quadrature encoder.

Software:

Delay Call	Since the Teensy 2.0 ATmega32U4 (16 MHz, 2K RAM) is significantly less powerful than the Teensy 4.1 ARM Cortex (600 MHz, 1024K RAM) I was originally going to use, special care had to be put in to extract every bit of performance from the hardware. Instead of blocking on hardware Input/Output, I created a very simple version of “threading” where other tasks can be executed in the background when waiting. This is a huge, necessary improvement over, for example, Arduino’s “delay(…)” function which simply burns CPU cycles in a loop for the specified amount of time.
Asynchronous	Again, since the Teensy 2.0 ATmega32U4 is significantly less powerful than the ARM Cortex I was originally going to use, I had to develop creative solutions to get around certain hurdles. Good DC motor current control for example requires a very high update rate to do well. That’s why I set up the processor’s ADC in “free running” mode as opposed to simply polling (and blocking on) ADC readings in the main loop.
Loop	The is the main control loop. This is where I will develop my more advanced controllers.
Initialization	This code sets up all the hardware before the robot runs.

Parts

Possible Challenges

Please list some of the challenges that your group foresee in working on your project.

I'll need access to an on-campus machine shop / makers space which might be difficult during COVID.
State-space modeling is a bit challenging. I'm currently taking Diff. Eq. though should be able to learn the rest online.
Failures / Breakage of my mechanical design might cause major set backs.
The reaction wheel might not have a high enough inertia to stabilize the robot. Would have to order new parts / rebuilt it.
The reaction wheel might not be perfectly balanced and could jiggle the robot.
In the renders above, if the robot were to fall, it would bash the reaction wheel and potentially damage the motor.