CDE4301 Innovation & Design Capstone

Our current progress in this CDE4301 capstone project has been made possible through the efforts and support provided by various individuals and organisations.

Project Supervisor:

We are profoundly grateful to Mr Lim Hong Wee for his invaluable guidance, mentorship and unwavering support. His efforts have been instrumental in helping us achieve the progress that we have made in this project thus far.

Industry Partner:

We thank Mr Sun ChunLei (CEO Red Dot Mobility) for his efforts in supporting our project thus far.

List of Acronyms

ABS: Anti-lock braking system

APAC: Asia Pacific

BDC: Brushed DC

BLDC: Brushless DC

CAGR: Compound Annual Growth Rate

CG: Center of Gravity

CMSIS: Common Microcontroller Software Interface Standard

DC: Direct Current

DC-DC: DC to DC

E2W: Electric two-wheeler

EMF: Electromotive Force

ESC: Electronic Speed Controller

HAL: Hardware Abstraction Layer

ICE: Internal Combustion Engine

IMU: Inertial Measurement Unit

IWP: Inertia Wheel Pendulum

KE: Kinetic Energy

Li-Po: Lithium Polymer

LQR: Linear Quadratic Regulator

MPC: Model Predictive Control

OEM: Original Equipment Manufacturer

PE: Potential Energy

PID: Proportional-Integral-Derivative

POC: Proof of Concept

PTW: Powered Two-Wheelers

PWM: Pulse Width Modulation

RW: Reaction Wheel

STM: STMicroelectronics

UART: Universal Asynchronous Receiver-Transmitter

1. Introduction

1.1 E2W Market

Governments across APAC are phasing out ICE vehicles, while drivers like rising fuel costs, environmental concerns and technological advancements are accelerating the shift toward electrification. The region’s E2W market (e-scooters and e-motorbikes) valued at USD 15.5 billion in 2024 and is expected to reach USD 56.8 billion by 2032, growing at a CAGR of 17.6%, with over 15 million E2W expected on Asian roads within the next few years^[1].

1.2 Industry Partner: Red Dot Mobility

We shall be focusing on the conceptual development of a self-balancing bike in collaboration with our industry partner Red Dot Mobility, that best suits APAC’s dense cities and their unique transportation landscapes and its unique challenges.

2. Problem Definition and Objectives

2.3 Problem Statement

“HMW keep an e-bike upright hands-off at 0–10 km/h in APAC stop-go traffic, so riders avoid tip-overs and fatigue without adding significant weight or range loss?”

We aim to eliminate low-speed instability at less than 10 km/h including standstill, via an on-board, active self-balancing system that maintains upright equilibrium without rider input.

3. Value Proposition

3.1 Value Proposition Canvas

Our value proposition canvas proposes how dangers of low-speed riding are addressed by improving low-speed stability for bikes.

Target audience: OEMs and E2W riders

4. Design Methdology and Concept Development

4.1 Design Statement

To identify stakeholder requirements, we conducted interviews with bike users and RedDot Mobility which leads us to 3 main points.

4.2 Design Solution

For all models used, refer to appendix A.

4.2.1 IWP Model

The IWP is chosen due to its relative simplicity to understand, low application complexity and a widely researched topic, making it an ideal starting point for us. The bike model consists of a pendulum and an inertia wheel, both rotating about the x-axis. When the pendulum falls to the side (θ ≠ 0), the angular velocity of the inertia wheel 𝜑’ is increased or decreased in the opposite direction to generate a reactionary torque 𝜏 to self-balance the system.

4.2.2 Linear Quadratic Regulator

The Linear Quadratic Regulator (LQR) is an optimal state-feedback control strategy applicable to systems expressed in linear state-space form. Given a system of the form x'=Ax+Bu, LQR computes a feedback gain matrix K_LQR such that the control law

drives the system states to zero while minimising a trade-off between control effort and state deviation. The gain is derived analytically rather than tuned heuristically, which makes LQR well-suited to multi-state systems where manual gain selection would be impractical.

For full explanation refer to appendix A.

4.2.3 1st Prototype (RC-Bike)

The aforementioned design concepts informed our decision to procure an RC-Bike prototype in the 1st-half of this project. This initial prototype was intended to serve as a POC (Proof-of-Concept) to evaluate the viability of said concepts in a physical application, and facilitate greater understanding of real-world implementation.^[4]

This RC-bike prototype utilised a reaction-wheel mechanism and a PID control algorithm to achieve self-balancing functionality at low speeds and during turning. Rigorous analysis of its system revealed a highly convoluted code architecture handling numerous non-core balancing operations. With limited resources, relevant expertise and time constraints, effectively scaling such a system to full-size would be overambitious. Hence, only the core self-balancing feature was brought over to the full-scale prototype.

5. Prototyping

This chapter presents the design and development of the final prototype, describes its key subsystems and documents the prototyping workflow undertaken.

5.1 Prototype Design Overview

The final prototype scales the RC-bike’s RW-based self-balancing principles onto a full-sized bicycle system. Research revealed 1 previous student project to have successfully utilised this mechanism to achieve a similar objective, providing reassurance about system feasibility.^[5] When the bicycle frame experiences lateral tilt forces, a reaction-wheel mechanism mounted perpendicular to the bike's length axis counters these forces by spinning rapidly in the opposing direction, generating a corrective torque moment that drives the frame back toward vertical equilibrium. Sustained operation of this mechanism constitutes the system's self-balancing functionality.

5.1.1 Technical Requirements and System Objectives

To function effectively within the operating range of ±1 to 20 degrees of lateral tilt, the RW must generate sufficient torque to overcome the frame's lateral tilt forces. Preliminary torque calculations (see Appendix A) established a gross motor torque requirement of 10.7 Nm, which informed all subsequent component selection decisions.

5.1.2 Bill-of-Materials (BOM)

Extensive market research was conducted prior to prototyping to source and select the necessary components for constructing an effective, functional prototype.

5.2 Mechanical System

The prototype’s mechanical subsystem comprises the bike frame and RW module.

5.2.1 Frame and Structural Components

The prototype is built around a robust full-scale bicycle frame measuring 1.09 × 0.97 m (L × H), weighing 12 kg with a centre of gravity at 0.52 m. These specifications were used to derive the torque requirements detailed in Appendix A.

5.2.2 Reaction Wheel Module (Assembly and Components)

Motor Type:

Market research identified Hub motors as the optimal motor type for this project.^[7] Their integrated rotor, stator, and built-in Hall sensors eliminate the need for external gearboxes or shaft alignment, reduce failure points, and offer a favourable torque-to-size and cost profile relative to alternative types.

Motor Model:

The HL6SD hub motor was selected following substantial research, supervisor recommendation and immediate availability, with datasheet specifications confirming it met the initial torque requirements. Component testing validated effective bidirectional programmability, adequate rated torque output, compact dimensions, and straightforward system integration, confirming the HL6SD for the final prototype.

For motor technical specifications, refer to Appendix D.

Motor Mount:

The motor mount was designed and 3D-printed (ABS) with supervisor assistance following frame procurement and centre-of-gravity analysis, then assembled and affixed to the frame.

Reaction-Wheel Assembly:

Subsequent testing on the assembled prototype revealed that the unmodified HL6SD produced insufficient torque to overcome the bicycle frame's lateral tilt forces. Following discussion with the project supervisor, the most viable corrective path (given limited physical space on the frame) was to increase the RW's effective mass. 64 metal bolts (28.667 g each) were arranged uniformly along the motor's circumference and secured with tape and zip-ties, adding 1.83 kg to the RW assembly. This modification increases the RW's rotational inertia, thereby increasing the reaction torque available for a given angular acceleration.

5.3 Electrical System Implementation

The electrical architecture of the final prototype mainly concerns motor control and power systems.

5.3.1 Motor Controller Selection

The initial motor controller used was an MX25-DC, selected based on prior integration with the HL6SD by the project supervisor. While it interfaced adequately at low voltages, testing at higher voltages revealed erratic motor control: voltage spikes during direction changes produced jerky motion and insufficient acceleration.

The root cause was identified as its duty-cycle-based architecture that was using an open-loop approach that maps PWM input directly to motor voltage and is inherently sensitive to supply voltage fluctuations.

This prompted a switch to a torque-mode controller. Torque-mode controllers operate in a closed loop by mapping input commands to motor current, which is directly proportional to torque, and regulate current internally to ensure stable output regardless of voltage variation.

Sourcing research identified the AQMD6020BLS-E2F as a suitable option, and was thus procured and configured to replace the MX25-DC. Empirical testing confirmed improved motion precision: directional changes were sharper, PWM ramping was smoother, and the motor response was more consistent, even in open-loop duty-cycle mode. This validates the AQMD for the final prototype and enables subsequent exploration of its torque-control mode.

For technical specifications of the motor controller, refer to Appendix D.

5.3.2 Power System Design

A variable 30V power supply was employed during initial prototyping and later replaced with a fixed 40V supply for the final prototype.

5.4 Embedded System Development

The embedded system incorporated in the final prototype links together the prototype’s mechanical, electrical and firmware sub-systems.

5.4.1 Microcontroller (MCU) Selection

Three microcontrollers were evaluated iteratively. The Arduino Uno was used initially for basic command testing, then replaced by the Arduino Mega 2560 for its expanded pin count. The Mega supported early PID proof-of-concept testing and motor stress validation; however, its limited processing power caused frequent crashes under the algorithm's computational load.

The STM32F407VGT6 was selected next for its high processing capability. However, it proved impractical in practice: STLink debugging was unreliable due to firmware compatibility issues, and porting the codebase across two IDEs (STM32CubeIDE and Arduino IDE) proved excessively time-consuming with negligible progress. Given time constraints, the STM32 was abandoned.

The ESP32-S3 DevKitC-1 was selected as the final microcontroller. It offered substantially greater processing power than the Mega while remaining straightforwardly programmable in Arduino IDE, unlike the STM32, and provided sufficient multi-purpose GPIO pins for the AQMD controller, MPU6050, and Hall sensor inputs. This combination of performance, usability, and I/O availability made it the optimal choice for the final prototype.

5.4.2 Sensor Integration

The MPU6050 6-axis IMU was retained from the previous semester's RC-Bike prototype, where its performance had already been validated.^[16] It provides the lean angle (θ, rad) and angular rate (θ’, rad/s) measurements that serve as primary state inputs to the LQR controller.

5.4.3 Firmware Development

Firmware development followed an iterative progression aligned with hardware upgrades. Early iterations on the Arduino platforms established basic bidirectional motor control and identified operational constraints, including a minimum direction-change interval to prevent the AQMD from dropping commands. PID control was implemented and validated on the Mega before the codebase was migrated to the ESP32-S3, where the control algorithm was upgraded to LQR with complementary-filter-based IMU fusion. Subsequent iterations incorporated Hall-sensor speed feedback, torque-mode output mapping, I²C fault recovery, and empirical PWM and gain tuning to address motor-induced electrical interference.

5.5 Software and Code Architecture

The final prototype relies primarily on an LQR control algorithm to control the motor and output the desired motion necessary for achieving self-balancing functionality. Hence, its software architecture can be delineated into 2 sections focusing on the computation of the LQR parameter values utilised in the control code, and the actual code program for the overall system.

5.5.1 LQR Computation

The LQR computation process is implemented through a Python script that generates the optimal feedback gain matrix for the controller. The script translates physical system parameters into a mathematical model, validates system properties, computes the optimal gains, and verifies stability.

For full explanation refer to Appendix B.

5.5.2 Code Architecture

This system’s code architecture is a layered closed-loop balancing controller for a RW-stabilized bicycle. It uses the MPU6050 to estimate bicycle lean angle and lean rate, hall sensors to estimate RW speed, and an LQR-based controller to compute the motor effort required to oppose the fall. That command is then converted into PWM, direction, and braking actions for the AQMD motor driver, with additional safety cutoffs and I²C recovery logic to preserve stability under noise and aggressive reversals. Collectively, these sections allow the RW to generate reaction torque in the required direction and magnitude to help the bicycle recover toward upright equilibrium. The code is implemented via Arduino IDE and is delineated into 6 core sections. For further details, refer to Appendix C.

5.6 Iterative Prototype Development

This section documents the prototype development workflow and timeline. For detailed timeline, refer to Appendix F.

Stage 1:

Focus was to connect the core components of the system and ascertain viable motor control. Components used were the HL6SD, MX25-DC, Arduino Mega, MPU6050.

Stage 2:

Procurement of Bike Frame and conceptualisation of mounting attachment.

Stage 3:

Design and assembly of mounting attachment and reaction-wheel assembly.

Stage 4:

Replaced MX25-DC with AQMD6020BLS-E2F.

Stage 5:

Replaced Arduino Mega with STM32F407VGT6.

Stage 6:

Replaced STM32 with ESP32-S3.

6. Testing and Experimental Setup

This chapter presents the sequential testing procedures and experimental setup utilized for calibrating the final prototype as described in Section 5.

6.1 Objectives and Scope of Testing

The testing process was structured to validate whether the system can achieve stable self-balancing on a stationary bicycle frame. The scope focuses on both control capability and electrical reliability, as both are necessary for successful operation.

The following testing objectives were defined:

Motor Strength: Verify that the motor can generate sufficient torque through rapid acceleration of the RW to correct tilt disturbances.
Motor Response: Ensure the motor can decelerate, brake, and reverse direction quickly, enabling timely corrective action during dynamic tilting.
Mode of Motion (RW Dynamics): Confirm that active braking during direction changes produces the required impulsive torque (jerk), which is critical for stabilisation.
System Reliability: Ensure consistent operation under repeated dynamic conditions without triggering overcurrent faults or I2C bus failures.

Scope Limitations:

Testing is conducted on a stationary bicycle frame (no forward motion).
Rider effects are excluded, in line with the project objective.
The system is evaluated primarily under controlled tilt disturbances (5-10 degree, up to 10 degree limit).

6.2 Experimental Setup

Figure 23 illustrates the experimental setup used for testing, calibration, and troubleshooting. The configuration replicates the final prototype while allowing controlled and repeatable testing.

6.2.1 Mechanical Configuration

6.2.2 Electronics and Integration

6.2.3 Stabilisation and Safety Measures

6.2.4 Testing Environment

This setup ensures that the system operates under realistic electrical and mechanical conditions, while maintaining sufficient control over external variables to enable repeatable and reliable testing.

6.3 Testing Methodology

The testing methodology was designed to identify the maximum achievable control performance while ensuring electrical reliability of the prototype. A structured, single-variable approach was used. Only one parameter was adjusted at a time while others were held constant, allowing direct attribution of observed effects to that parameter.

Data were collected through direct physical observation and quantitative analysis by the monitoring of embedded system diagnostics during each tuning phase. Performance metrics were assessed across three dimensions:

Responsiveness (s): the speed with which the RW reverses to counteract a change in lean direction. Recorded as time lag between when u_cmd is first sent and omega reaches top speed in test waveforms.
Number of interruptions: the presence of warning messages that indicates faults (I2C warning, MPU6050 zero data warning) during the entire duration of testing.

NOTE: Interruptions are defined as both (I2C disruption + Reboot) and system crashes.
Deceleration (rad s^-2): the reduction in the bicycle’s angular velocity during tilt tests can only be due to counter-torque by the RW, hence a higher deceleration means stronger balancing effect.

Binary outcomes, namely I2C bus crashes and overcurrent faults, were treated as hard failure conditions and used to define absolute operating boundaries rather than points on a continuous scale.

For detailed test steps, refer to Appendix F.

6.4 Prototype Testing Procedures

6.4.1 Phase 1: K-matrix Gains Test

Goal

Identify a set of LQR weighting matrices Q and R that yields K-matrix gains capable of stabilising the bicycle without saturating the motor driver or inducing I2C bus faults.

Results:

Final: Q = [100 50 1 10], R = [800], K = [-1628.118868 -516.442280 -0.035355 -2.118065]

6.4.2 Phase 2: Tuning ‘PWM_MIN_RUN’

Goal

Determine the minimum PWM duty below which the motor stalls rather than rotates, and set PWM_MIN_RUN to eliminate this deadband.

Result

PWM_MIN_RUN was determined to be unchanged below 1, steps and results can be found in Appendix F.

6.4.3 Phase 3: Finding the EMI Limit (Tuning ‘PWM_STEP’)

Goal

Find the maximum PWM slew rate the electrical system tolerates before inductive current transients during direction reversals crash the I2C bus.

Results

Final: PWM_STEP = 7

6.4.4 Phase 4: Controller Authority (Tuning ‘LQR_SCALE_FACTOR’)

Goal

Scale the LQR output voltage to provide sufficient corrective torque for active balancing, without exceeding the current limit or inducing high-frequency instability.

Results

6.4.5 Phase 5: Reversal Braking Timing (Tuning 'REVERSE_BRAKE_HOLD_MS')

Goal

Find the minimum brake hold duration during motor direction reversals that still allows the motor to decelerate safely before receiving an opposing torque command. Too short a pulse risks overcurrent faults and I2C bus crashes when opposite drive is applied before the rotor has slowed; too long a pulse introduces control lag that degrades balancing performance during rapid tilt corrections.

Overcurrent was identified as a greater threat due to it significantly increasing the likelihood of system failure, hence this range of brake_hold duration values was selected to ascertain the optimal (simulated) brake performance while ensuring no overcurrent.

Results

7. Results and Analysis

7.1 Data Collection and Processing

Performance data were collected by monitoring the serial output of the ESP32-S3 during each trial. The embedded firmware streamed five channels at each control loop iteration: timestamp, pendulum angle (θ, degrees), angular velocity from the MPU6050 IMU (rad/s), LQR control command (u_cmd), and RW speed (ω, rad/s). These data were copied directly from the serial monitor and pasted into Excel for further analysis.

7.2 System Performance Analysis and Evaluation

7.2.1 Tuned Parameter Summary

7.2.2 Phase 1: LQR Gain Matrix (K-Matrix) Selection

Four Q/R combinations were evaluated by varying R[0,0] from 1000 down to 100 while holding Q fixed at [100 50 1 10]. The results are in Table 8.

Responsiveness improved monotonically as R decreased (K gains increased), falling from 1.6 s at R = 1000 to 1.4 s at R = 100. This is physically expected since higher gains command larger corrective voltages for a given state error, accelerating the RW more aggressively. Deceleration followed the same trend, rising from 60.3 rad s⁻² at R = 1000 to 71.5 rad s⁻² at R = 100, confirming that stronger gains translate directly into greater counter-torque output.

However, the fault record reveals a clear reliability boundary. R = 1000 and R = 800 both produced zero interruptions. Reducing R to 500 resulted in one reboot event, indicating that the associated current transients were approaching the motor driver’s tolerance threshold. At R = 100 an I2C bus crash occurred, representing a hard failure that renders the gains operationally unusable regardless of their control performance.

The operating point R = 800 was therefore selected. It achieves a responsiveness of 1.5 s and a deceleration of 64.5 rad s⁻² giving a modest reduction from the highest-gain case, while maintaining a completely clean fault record across the trial.

The corresponding gain vector is K = [−1628.118868, −516.442280, −0.035355, −2.118065].

7.2.3 Phase 2: Motor Deadband Elimination (PWM_MIN_RUN)

Phase 2 sought to identify the minimum PWM duty cycle below which the motor stalls rather than rotates, so that PWM_MIN_RUN could be set to eliminate this deadband. Testing confirmed that the motor responds to a duty cycle of 1 with no evidence of stalling. PWM_MIN_RUN was therefore retained at its initial value of 1, and no corrective adjustment was required.

The absence of a significant deadband is attributable to the low static friction of the BLDC motor-and-driver combination used in this prototype. Full details of the test procedure and observations are provided in Appendix F.

7.2.4 Phase 3: EMI Threshold Identification (PWM_STEP)

PWM_STEP controls the maximum change in PWM duty cycle applied per firmware cycle, effectively setting the slew rate of the motor drive signal. Rapid direction reversals generate inductive current transients on the power rails, and beyond a threshold slew rate these transients couple into the I2C bus and cause communication failures with the MPU6050.

Five values were tested by forcing five consecutive rapid direction reversals at each setting (Table 10, Section 6.4.3). Responsiveness improved with each increment: from 1.0 s at PWM_STEP = 4 to 0.7 s at PWM_STEP = 7 and 8. However, reliability degraded above PWM_STEP = 5. At PWM_STEP = 6 a single reboot occurred; at PWM_STEP = 7 a reboot recurred; at PWM_STEP = 8 the I2C bus crashed outright on the final reversal.

The crash at PWM_STEP = 8 establishes the hard EMI boundary. PWM_STEP = 7 is selected as the operating value as it delivers the best responsiveness achievable (0.7 s) before the bus crash threshold, while accepting the reboot event as an occasional but non-fatal fault. The one-step margin below the crash value provides protection against variability in load conditions and power-supply transients during real operation.

7.2.5 Phase 4: Controller Authority (LQR_SCALE_FACTOR)

LQR_SCALE_FACTOR is a scalar multiplier applied to the full LQR output voltage before it is converted to a PWM duty cycle. It acts as a gain scheduling parameter that decouples the theoretical LQR output from the physical authority actually commanded to the motor driver, providing a practical means to limit peak current demand without modifying the underlying K matrix.

Six scale factors from 0.1 to 1.0 were tested with PWM_STEP = 7 and PWM_MIN_RUN = 1 fixed. The results (Table 11, Section 6.4.3) show a consistent inverse relationship between scale factor and responsiveness: as authority increases from 0.1 to 1.0, response time falls from 1.2 s to 0.7 s. Deceleration rises steeply at lower scale factors and begins to plateau above 0.6, growing from 16.1 rad s⁻² at 0.1 to 79 rad s⁻² at 1.0.

The interruption pattern is non-monotonic. A reboot occurred at scale factor 0.2 but not at 0.4 or 0.6, suggesting that current transients at low authority can still cause isolated faults. Reboots reappear at 0.8 and 1.0, reflecting the higher sustained currents at full authority.

LQR_SCALE_FACTOR = 1.0 was selected as the operating point. It provides the highest deceleration and fastest response achievable within the hardware envelope. The reboot events observed at this setting are single occurrences that do not constitute an I2C bus crash and are recoverable by the firmware watchdog.

7.2.4 Phase 5: System Stability (REVERSE_BRAKE_HOLD_MS)

The results demonstrate a clear trade-off between electrical safety during motor direction reversals and overall control responsiveness. Shorter brake hold durations (<100 ms) result in high responsiveness but insufficient deceleration of the motor rotor, leading to significant current spikes, overcurrent risk, and I2C instability, which caused the system to fail extremely prematurely. Increasing the hold duration was identified as a means to improve system stability by allowing the rotor to slow sufficiently before reverse torque is applied.

A transition region is observed at 100-150 ms, where partial improvement in stability is achieved but consistent safe operation is not guaranteed. At this range, ~1 overcurrent interruption was observed per test. Beyond 200 ms, the system reaches the minimum hold duration that ensures reliable braking across repeated reversals without triggering overcurrent or communication failures. This yielded minimal additional stability benefits while unnecessarily degrading responsiveness due to increased control dead time.

Further analysis to ascertain response degradation as a result of increased brake_hold duration was then conducted by obtaining the correlation coefficient of the u_cmd and omega waveforms in each test, which indicates the time-lag between the waveforms corresponding to responsiveness. Results indicate that there is an inverse relation between system responsiveness and stability.

REVERSE_HOLD_BRAKE_MS = 100ms: Correlation-Coefficient: 0.805847
REVERSE_HOLD_BRAKE_MS = 150ms: Correlation-Coefficient: 0.800191
REVERSE_HOLD_BRAKE_MS = 200ms: Correlation-Coefficient: 0.782760

Therefore, 200 ms is selected as the optimal value (in concert with the already-established optimal parameter values), as it represents the lowest duration that satisfies the safety requirement whilst preserving as much responsiveness as possible. This aligns directly with the objective of minimizing reversal delay without compromising electrical and system stability.

7.3 Discussion of Observed Trends

Across all tuning phases, system performance was consistently limited by electrical interactions between the motor drive and sensing subsystems rather than by the LQR control law itself. Parameters such as gain selection, PWM slew rate, and brake timing were constrained by the onset of electromagnetic interference (EMI) and transient current effects. This indicates that the control architecture is fundamentally sound, with performance bounded by hardware limitations (see Section 9.2).

7.3.1 Trend 1: Overcurrent during rapid reversals

Observation:

At low brake hold durations (REVERSE_BRAKE_HOLD_MS ≤ 200 ms) and moderate-to-high controller authority (LQR_SCALE_FACTOR ≥ 0.2), repeated overcurrent warnings were observed during rapid alternating tilt tests, leading to imminent system failures.

Threshold:

Stable operation was consistently achieved at REVERSE_BRAKE_HOLD_MS ≥ 200 ms, where reversals were completed reliably without overcurrent faults while retaining maximum possible responsiveness.

Implication:

This behaviour indicates that reversals were initiated before sufficient rotor deceleration, resulting in transient current spikes. Increasing brake hold duration reduces this effect by allowing energy dissipation prior to reversal (mechanism discussed in Section 9.2.2). However, this applies a minute distortion to the LQR control sequence, causing the measured motor output waveform to slightly lag the motor command waveform, reducing system response intervals.

7.3.2 Trend 2: I2C bus crash due to EMI overload

Observation:

At higher PWM slew rates (PWM_STEP ≥ 8) and elevated controller aggressiveness, the system exhibited:

Repeatable I2C bus crashes during direction reversals
Gradual drift in θ_deg under sustained motor excitation
Increased I2C latency preceding failure

Threshold:

A sharp transition was observed between stable operation at PWM_STEP ≤ 7 and consistent failure at PWM_STEP = 8. PWM_STEP = 7 was selected as the operating value, representing the highest slew rate before the hard crash boundary.

Implication:

These observations indicate a clear EMI threshold governed by current slew rate rather than absolute current magnitude. The degradation manifests in two forms:

Hard failure: Complete I2C bus lock-up
Soft failure: Accumulated IMU drift leading to divergence of the estimated tilt

Both behaviours are consistent with EMI coupling into the I2C lines, corrupting sensor data and propagating through the control loop (see Section 9.2.1).

7.3.3 Trend 3: IMU and I2C Bus Lag Under Motor Excitation

Observation:

Increasing LQR_SCALE_FACTOR improved responsiveness and disturbance rejection monotonically across all tested values. However, at scale factors of 0.2, 0.8, and 1.0, reboot events were observed, reflecting the higher sustained currents and switching activity at elevated authority. No I2C bus crash occurred at any scale factor, making all reboot events recoverable.

Threshold:

Fault-free operation was achieved at LQR_SCALE_FACTOR = 0.1, 0.4, and 0.6. The final operating point of 1.0 was selected for maximum control authority, accepting occasional reboots as tolerable. A scale factor of 0.6 remains a fault-free fallback at 65.5 rad s⁻² deceleration.

Implication:

This demonstrates that control performance is not limited by the LQR design itself, but by the electrical constraints of the system. Higher control authority increases current demand and switching activity, which in turn amplifies EMI and transient effects. The selected parameters therefore represent the maximum achievable performance within the hardware limits (see Section 9.1.2 and Section 9.2).

7.4 Comparison with Theoretical Predictions

The LQR design was derived from a linearised state-space model of the bicycle RW system under the assumptions of small-angle operation, a rigid frame, and unconstrained actuator authority. The following deviations from theoretical predictions were observed in practice.

8. Fulfilment of Deliverables

This chapter identifies the key project deliverables to evaluate the overall success of the project.

8.1 Intended Project Deliverables

The intended project deliverable was to develop a full-scale prototype by implementing a RW mechanism on a bicycle frame to achieve self-balancing functionality at stationary. This involved the following milestones:

Design a working physical prototype for effectual testing of balancing RW mechanism.
Programming a HL6SD motor to achieve motion control necessary for self-balancing.
Determine the viability of a LQR control algorithm for implementing self-balancing firmware.

8.2 Achieved Outcomes

As of the time of writing this report, the following project milestones have been achieved:

Successful design and implementation of a physical self-balancing prototype
Successful validation of LQR control algorithm suitability, including offline gain computation, firmware integration, and structured tuning phases
Confirmation that the RW generates meaningful corrective counter-torque at standstill, with peak deceleration of 79 rad s⁻², demonstrating that the physical operating principle is sound

Project objectives that have yet to be achieved are:

Consistent, unsupervised self-balancing functionality under real-world conditions.

8.3 Evaluation of Project Success

The prototype validated the proof-of-concept for RW-based lateral stabilisation on a full-scale bicycle frame, confirming that an LQR controller operating on IMU-derived state feedback can generate active corrective torque at 0 km/h, precisely the operating condition where conventional steering-based stabilisation fails. This directly addresses the core premise of the problem statement.

However, full satisfaction of the design objective was not achieved within the current hardware envelope. The mandatory 200 ms reversal dead time, the RW's susceptibility to angular momentum saturation under sustained disturbances, and the EMI-imposed ceiling on controller authority collectively prevented the system from maintaining unsupervised upright equilibrium during free-standing trials. The prototype therefore cannot yet be characterised as a deployable hands-off balancing module for e-bike applications.

Nonetheless, the 12 weeks of design, prototyping, and structured testing have produced outcomes of tangible engineering value: the failure modes are well-characterised, the hardware constraints are quantified, and a clear path to a functional system is documented in the recommendations of Section 9.3. The gap between the current prototype and the stated objective is one of hardware limitation rather than control architecture, and the LQR-based RW approach remains a viable foundation for future development.

9. Limitations and Recommendations for Future Work

9.1 Identified Limitations and Justifications

9.1.1 Simplified Dynamic Model

The LQR controller was designed using a linearised RW inverted pendulum (RWIP) model with simplifying assumptions: point-mass approximation, small-angle linearisation, and ideal actuator behaviour.

Consequences:

Parameter mismatch with the physical system: The distributed mass of the bicycle introduces deviations in centre-of-mass location and inertia, resulting in steady-state lean bias and requiring empirical correction.
Reduced accuracy under large disturbances: For tilt angles of 5–10 degrees, the small-angle approximation introduces non-negligible error, leading to underestimation of gravitational torque and discrepancies in required control effort.
Implicit compensation through gain scaling: The experimentally determined LQR_SCALE_FACTOR = 1.0 indicates that full theoretical gain authority was applied. However, the associated reboot events at this setting suggest the hardware was operating at its electrical ceiling. The scale factor therefore did not serve as an attenuation mechanism for modelling error in this case; instead, modelling inaccuracies were absorbed implicitly through the empirical tuning of PWM_STEP and REVERSE_BRAKE_HOLD_MS, which constrain actuator behaviour in ways the linear model does not capture.

Justification:

A simplified point-mass model was adopted because full physical characterisation of the bicycle including experimental determination of the centre-of-mass location and rotational inertia tensor via pendulum swing tests or force-plate measurement was outside the project scope. The linearised RWIP formulation is well-established in the literature as a tractable starting point for RW balance control, and its gains are known to provide adequate closed-loop stability within reasonable margins even when the physical parameters are only approximately known. The results confirm that stability is ultimately constrained by electrical and actuator limits, not solely by model fidelity.

9.1.2 Reaction Wheel Moment of Inertia

The RW used for this prototype has limited radius and mass, resulting in a relatively low moment of inertia.

Consequences:

Rapid saturation under closed-loop control: Under closed-loop control, the controller frequently commands high torque even for moderate tilt angles. With low inertia, the wheel accelerates rapidly towards its mechanical speed limit, beyond which no additional corrective torque can be generated. This saturation mechanism directly explains the instability observed at LQR_SCALE_FACTOR ≥ 0.4 (Section 7.3.3): at this gain level, the control demands exceed the angular momentum budget available before the next reversal event is required, leading to a rapid succession of saturations and reversals that destabilise the system.
Increased sensitivity to tuning parameters: The limited inertia necessitates careful tuning of LQR_SCALE_FACTOR and PWM_STEP to avoid excessive torque commands that accelerate the wheel unnecessarily, as the overcurrent onset at PWM_STEP ≥ 8 (Section 7.3.1) is partly a consequence of the high slew rates demanded under low-inertia conditions.

Justification:

The RW dimensions were selected based on availability and weight constraints imposed by the bicycle frame geometry. Additionally, the limitation was not fully captured in the design phase, as theoretical calculations did not account for sustained high-torque demand under LQR control. Despite this, proof-of-concept was achieved within a constrained operating envelope through parameter tuning.

9.2 Technical Challenges Encountered

9.2.1 I2C Bus Disruption from Motor EMI

The most persistent technical challenge throughout development was EMI from the BLDC motor corrupting communication on the I2C bus shared by the MPU6050. As documented in detail in Section 7.3, inductive kickback transients generated during motor current switching coupled onto the SDA and SCL signal lines through the shared power ground and parasitic capacitance in the wiring harness.

The disruption manifested as:

Hard failure: Complete I2C bus lock-up, immediately detectable from serial output.
Soft failure: The complementary filter accumulated corrupted gyroscope frames before a hardware fault was detectable, causing theta_deg to drift from the physical lean angle. The resulting erroneous corrective command further excited the motor, creating a positive feedback loop between sensor corruption and motor excitation.

Possible mitigation via hardware electromagnetic measures including decoupling capacitors and physical signal isolation, was not implemented as implementing and verifying these changes required additional PCB rework and wiring modifications that were deferred to avoid disrupting a partially functional prototype during the testing window. Software-level mitigations (reduced I2C clock speed, bus timeout, extended fault tolerances) were applied instead and proved sufficient to maintain operation within the tuned parameter boundaries, at the cost of a constrained operating envelope.

9.2.2 Motor Overcurrent During Rapid Direction Changes

The combination of a high back-EMF at elevated rotor speeds and a sudden demand for current in the opposing direction during reversal caused the back-EMF and applied voltage to momentarily add rather than oppose, driving a transient spike that can significantly exceed the continuous rating. The empirical finding that the I2C bus failed before the motor at PWM_STEP = 8 suggests the sensor subsystem was the more sensitive component, and that overcurrent protection was activating concurrently with the I2C disruptions.

The practical consequences were:

Overcurrent faults were observed during test sessions involving rapid direction reversals, most acutely at higher PWM_STEP values and elevated controller authority. The motor, selected for a rated current exceeding values reported in online implementations, nonetheless produced transient current spikes during high-dI/dt switching events that exceeded the driver's protection threshold. The empirical finding that the I²C bus failed before the motor at PWM_STEP = 8 suggests the sensor subsystem was the more sensitive component, and that overcurrent protection was activating concurrently with the I²C disruptions.
The 200 ms brake hold introduced in Phase 5 partially addresses this by allowing the rotor to decelerate below REVERSE_ZERO_OMEGA before the opposing drive is applied, reducing back-EMF at the moment of current reversal. However this introduces a corresponding control dead time that degrades balancing performance under large disturbances.

A motor with a higher inductance or a driver with configurable current-ramp limiting would have mitigated the transient amplitude without requiring a long brake hold. Such hardware was not available within the project budget and procurement timeline. The brake hold approach was adopted as the most immediately implementable solution given the available components.

9.2.3 ESP32-S3 Firmware Upload Failures

Firmware uploads to the ESP32-S3 failed when the motor driver power supply remained energised. The suspected mechanism is residual current flow through the PWM signal line (GPIO14 to the AQMD IN1 input), which back-biases the GPIO pin during the USB bootloader’s control of the boot strapping pins. Because the motor driver supply shares a ground reference with the ESP32-S3, the driver’s input stage can source or sink small currents through signal lines even with no active PWM command.

This required powering down the motor driver before every firmware flash, then re-powering and re-executing the IMU calibration sequence. In practice this added several minutes to each development iteration. Ultimately, the failure mode was intermittent and only reproducible when the motor supply was connected during upload, making it straightforward to work around procedurally.

9.2.4 Incomplete Motor Characterisation

The motor was procured based on rated current and approximate KV specifications from the manufacturer’s product listing. A full datasheet was unavailable, and the torque constant Kt, back-EMF constant Ke, winding resistance R, and winding inductance L were estimated from these limited parameters rather than measured directly.

The practical consequences were:

EMI threshold is uncertain as an underestimate of L (governs the amplitude and duration of inductive kickback transients) would predict a higher safe PWM_STEP than the hardware sustains, consistent with I2C failure at the modest slew rate of PWM_STEP = 8 (Section 7.3.2). Without a measured value, it is not possible to determine whether the PWM_STEP = 7–8 failure transition is intrinsic to the motor or could be shifted by hardware EMC improvements alone.
Without measured values of Kt and Ke, it is also not possible to accurately relate the LQR’s computed Vin output to actual shaft torque, introducing a scaling uncertainty between the designed and implemented control law. This was absorbed by the LQR_SCALE_FACTOR parameter, which effectively became a lumped correction factor for the combined uncertainty in motor constants, model parameters, and driver characteristics.

Direct motor characterisation via locked-rotor current measurement and back-EMF sweep testing requires a controlled test rig with a calibrated torque sensor or precision current source, which was not available in the project laboratory. The motor was instead characterised empirically through the tuning procedure itself, which produced a functional system but limits the transferability of results to a revised hardware configuration.

9.3 Recommended Improvements

9.3.1 Hardware EMC mitigation

Methods:

Install bulk decoupling capacitors (100 μF + 100 nF) at motor driver supply terminals.
Add ferrite beads on motor phase leads
Route I2C harness ≥50 mm from power wiring and use shielded twisted-pair for SDA/SCL.

Eliminating the inductive coupling failure mode would remove the PWM_STEP ceiling at 7 and reduce the need for the 200 ms brake hold, directly increasing achievable control bandwidth and balancing performance. With EMC mitigation in place, higher LQR_SCALE_FACTOR values could be sustained without the reboot events observed at the current operating point.

9.3.2 Refined system identification

Method:

Measure motor Kt, Ke, R, and L directly via locked-rotor and back-EMF tests.
Characterise actual mass distribution and centre-of-mass of bicycle.

Reduces parametric uncertainty in the state-space model and allows the LQR solver to produce gains that match the physical system rather than an approximated model.

9.3.3 Higher-fidelity dynamic model

Extend the linearised RWIP model to include wheel gyroscopic precession, frame flexibility (or verify rigidity assumption), and actuator dynamics (motor electrical time constant, driver dead time). This closes the gap between theoretical LQR predictions and observed closed-loop behaviour, particularly the unmodelled 300 ms reversal dead time and the gain authority reduction.

9.3.4 Incomplete Motor Characterisation

Replace the complementary filter with a discrete-time Kalman filter incorporating the motor current as a measurement input to detect and reject EMI-induced outliers.

Provides statistically optimal state estimation, suppresses corrupted IMU frames at the filter level rather than through conservative fault tolerances, and allows a higher LQR_SCALE_FACTOR to be used safely.

9.3.5 ESP32 upload reliability fix

Add a power isolation switch or MOSFET on the motor driver supply that can be de-energised before firmware uploads, or use the ESP32-S3’s USB-OTG port with the motor supply disconnected. Removes the upload failure mode caused by residual PWM line current during programming, reducing development iteration time.

9.3.6 Reaction wheel redesign

Replace the current wheel with one of larger radius and higher rim mass to increase the moment of inertia. Concentrate mass at the periphery (e.g. a heavy rim with lightweight spokes) to maximise I for a given total weight. Re-validate the RWIP model parameters after the change.

Reduces the rate of wheel speed accumulation for a given corrective torque, extending the time window before saturation and allowing the LQR to operate at higher scale factors without immediately exhausting angular momentum authority.

10. Impact and Visibility.

10.1 Potential Applications for Real-World Implementation

We believe that there are considerable takeaways from this project that hold promise for implementation in real-world applications. Self-balancing functionality sees great potential in fields like urban commuting, autonomous mobility solutions, assistive cycling and fall prevention, making this a field worthy of further study and development.

10.2 Contribution to Engineering Knowledge

Our project has successfully showcased the viability of using control algorithms like PID and LQR for such engineering projects and systems that involve extremely precise control and handling. The structured four-phase tuning methodology we utilized: progressing from gain selection to EMI limit identification to controller authority, offers a replicable framework for embedded control development on hardware-constrained platforms, and the documentation of hardware failure modes such as I2C bus corruption under motor EMI and overcurrent during rapid reversals contributes practical knowledge that is underreported on RW balance systems where theoretical and electrical boundaries must be identified empirically. Our prototype also epitomises simplicity by utilising minimal components to achieve considerable performance, which may well serve as inspiration for future student-led research and design projects.

10.3 Opportunities for Further Research and Development

Looking ahead, there are significant areas for improvement to the existing prototype, including modifying the RW setup to further increase its mass and diameter, to improve the performance of the system to achieve reliable self-balancing functionality as per the initial objectives.

10.3.1 Lateral Steering and Forward Propulsion

The current prototype operates exclusively in the lateral balancing plane, with no mechanism for controlled forward motion or steering. A practical self-balancing bicycle must account for forward velocity and directional changes, which introduce additional state variables including yaw rate and steering angle.[18] Re-deriving the state-space model to include forward velocity as a state variable and extending the LQR to a full lateral-longitudinal control law would be the logical next step.

10.3.2 Nonlinear and Adaptive Control

The current LQR design is valid only in a small margin about the vertical equilibrium. For operation at larger lean angles, a nonlinear control strategy would provide more robust stability guarantees. Candidate approaches include linear parameter-varying (LPV) control, in which a family of LQR controllers is synthesised at different operating points and interpolated online, or model predictive control (MPC), which explicitly handles actuator constraints, including the reversal dead time and current limits, within the optimisation.[19] An adaptive variant that updates model parameters in real time as system characteristics change with sustained load and battery state of charge would also further improve performance consistency.

10.3.3 Autonomous Bicycle Applications

The self-balancing function enhanced with navigation stack can be directly applicable to lightweight cargo delivery in urban environments.[20] Bicycles occupy significantly less road space than vans, produce no direct emissions, and can access infrastructure unavailable to four-wheeled vehicles. As e-commerce demand continues to grow, lightweight autonomous two-wheeled platforms represent a promising and underexplored complement to the delivery robots and drones that currently dominate commercial deployments.

Appendix A: Problem, Value proposition & Concept Selection

1. Low Speed Instability

Due to the inherent design of a bike, the difficulty riders face in low-speed conditions rises significantly. As speed reduces, effort and steering input correction required to attain stability increases sharply^[5]. This is a common phenomenon faced by riders in high traffic conditions.

Therefore, innovations that can help improve rider safety, including minimising balance loss at low-speeds among riders, are imperative.

2. Dense Traffic

In traffic-heavy cities like Bangkok, Jakarta, and Mumbai, where the average speed in peak hours is under 25 km/h, the convenience offered by bikes are hampered as riders spend nearly half their time balancing between low speeds and a stop-go flow^[6]. Moreover, this cycle of starting and stopping requires continuous input from a rider to achieve stability, significantly adding to rider fatigue, further exacerbating the safety concerns^[5].

These have contributed to a rising incidence of motorcycle crashes occurring at low speeds, with over 5% of crashes occurring at impact speeds below 10 km/h. Additional factors include decision and perception failures from riders as well as environmental factors like road defects and hazards^[7].

3. Value Proposition Statement

The IWP self-balancing bike enhances rider safety and comfort by actively stabilising bikes at low speeds (0–10 km/h) and at standstill. By automatically detecting and correcting balance deviations through a robust control algorithm and precise angle sensing, the system eliminates the need for continuous rider correction in stop-go traffic, reducing fatigue, minimising tip-overs, and improving overall ride safety and confidence.

4. Objectives and Scope

For the purpose of this project, the term “bike” collectively refers to bicycles, e-bikes, and e-motorbikes, as they share the common dynamic characteristic of being an inverted pendulum system. This project’s scope comprises the design, development, and testing of a full-scale self-balancing bicycle prototype.

The primary objective is to design and validate a self-balancing mechanism capable of maintaining upright stability of a bicycle (with and without rider) at low speeds (0–10 km/h) and at rest, through real-time angle detection and corrective actuation. The project will focus on:

Developing a robust control algorithm for balance correction.
Integrating sensor and actuator systems for precise tilt detection and response.
Evaluating stability performance, response time, and rider comfort under simulated low-speed conditions.
Designing a compact system for seamless integration within the existing bicycle frame.

The scope is limited to low-speed stabilisation and does not extend to high-speed dynamics, collision avoidance, or large-scale vehicle integration. The deliverables include system design documentation, control validation through simulations and prototype testing, and performance evaluation against defined stability metrics.

5. Design Methodology

5.1 Current Low-Speed Stability Solutions

Research highlights several attempts to mitigate low-speed instability in two-wheelers at present.

1. Enhanced ABS

ABS are installed in most motorcycles today, providing better safety and stability in dynamic situations through lean and pitch angle-dependent braking control. Although highly effective at maintaining stability at high speeds and preserving traction during cornering, ABS are less effective at low speeds due to weak sensor signals which may result in unwanted ABS activation^[8]. As such, most ABS automatically cut-off below speeds of 10–20 km/h^[9], thus for this project we will not be considering ABS as a low-speed stability method.

2. Three-wheeled bikes

These show improved static stability as well as weave stability over two-wheeled bikes, but in certain situations such as under low-speed, tight-turn conditions, the dynamic behavior (stability and response characteristics) of a three-wheeler becomes very similar to that of a two-wheeler^[10]. Moreover, three-wheelers deviate from the traditional design and riding experience valued by two-wheeler enthusiasts. In line with this, our industry partner whose product range is centred on two-wheelers intends to pursue stability solutions without shifting towards a three-wheeler configuration.

3. AMSAS

Mechanisms that alter and assist in steering input to provide steering assist input at low speed^[11] show promise in research prototypes but introduce mechanical complexity and are not yet production-ready. As AMSAS relies on wheel movement and steering to improve stability, it becomes less effective at a stop.

4. Gyroscopic systems

Imbalances are addressed by high-speed rotating discs with gimbal actuation, providing immediate active correction at lower speeds. However, the system consumes a lot of power to maintain the high rotational speeds and precision rates.^[12]

5.2 Industry Landscape

The current market-ready solutions do not concurrently address the issue of instability at low-speed and at rest, while keeping to a two-wheeler configuration. From our market research, we identified our competitive advantages of low- and zero-speed stability within the frame of a two-wheeled bike configuration.

6. Concept Selection

The selection criteria for the self-balancing system for low-speed stability prioritises fast torque response, well-damped control, compact and safe integration.

Appendix B: Mathematical Derivations

1. Inverted Pendulum Model of Bicycle Dynamics

A bike is fundamentally an inverted pendulum (Figure 7), where its mass M or center of gravity is above its pivot point. The system rotates about the x-axis by a roll angle θ. The various forces acting on the motorcycle are due to weight Mg, normal reaction N and lateral force F_y. To allow a bike to remain upright (θ ≈ 0), balancing forces need to be continuously applied.

2. DC Motor Model

Motor torque τ is related to armature current ia by a motor torque constant Kt by,

3. State Space of Dynamic System

The state-space representation of the linear dynamics system can be written as

where x is the state vector, u is the control input in the form of DC motor voltage and y is the output vector. From the dynamic equations, the IWP system has four elements: angle of pendulum (θ), the angular velocity of pendulum (θ'), the angle of RW (ϕ), and the angular velocity of RW (ϕ'). The state vector of IWP system is written as

The state-space model undergoes approximate linearization around the operating point (x^∗, u^∗). The matrix A and B is computed from the system Jacobians. Assume that while the IWP moves only small deviations in the angular position θ ≈ 0. This means that we can linearize around an unstable equilibrium point so that the model will be more suitable for controller design. Using this fact, the approximations are

4. Linear Quadratic Regulator

Cost Function

The controller is designed by minimising the infinite-horizon quadratic cost functional J
J = ∫(x^TQx + u^TRu + 2x^TNu)dt
Equation 8: Cost function [3]

where Q is a positive semi-definite state weighting matrix, R is a positive definite input weighting matrix, and N captures cross-coupling between state and input penalties. Each term in the integrand has a clear physical interpretation: x^TQx penalises deviations of the system states from equilibrium, while u^TRu penalises the magnitude of the control input. Minimising J therefore encodes the engineering objective of returning the system to equilibrium quickly without expending excessive actuator effort.

Optimal Gain

The optimal feedback gain is given by
K_LQR = R^-1(B^TS + N^T)
Equation 9: Feedback gain [3]

where S is the unique positive definite solution to the Algebraic Riccati Equation (ARE):
A^TS + SA − (SB + N)R^-1(B^TS + N^T) + Q = 0
Equation 10: ARE [3]

Since the state and input penalties in this system are independent, the cross-weighting term is set to N = 0, which simplifies the ARE to
A^TS + SA − SBR^-1B^TS + Q = 0
Equation 11: Simplified ARE

Weight Selection

The closed-loop performance is governed entirely by the choice of Q and R. Increasing a diagonal entry of Q places greater penalty on the corresponding state, causing the controller to suppress deviations in that state more aggressively at the cost of larger control inputs. Conversely, increasing R penalises actuator effort more heavily, resulting in a more conservative controller with slower but smoother responses.

The Q/R ratio effectively determines the bandwidth and aggressiveness of the controller, where a high Q/R ratio produces fast, aggressive stabilisation, while a low Q/R ratio yields slower, more energy-efficient control. In practice, the weighting matrices are iteratively adjusted, informed by simulation and physical constraints such as actuator saturation until the desired balance between response speed and control effort is achieved.

5. Motor Torque Requirement Calculations

Geometric parameters

L1 = 0.52 # Distance from lean pivot (tyre contact) to bicycle CoM (m)
L2 = 0.22 # Distance from lean pivot to RW CoM (m)

Mass parameters

m1 = 12 # Bicycle + rider effective mass (kg)
m2 = 5 # RW mass (kg)
I1_cm = 1.15 * m1 * L1² # Bicycle CM inertia (kg·m²), modelled as a point mass of CoM at height L1

Physical constants

g = 9.81 # Gravitational acceleration (m/s²)
dp = 0.01 # Bicycle lean viscous damping coefficient (N·m·s/rad)

Motor/reaction-wheel parameters

r_rw = 0.09 # RW radius (m)
J = 0.03126 # RW moment of inertia about spin axis (kg·m²)
Ng = 1 # Gear ratio (motor shaft to wheel shaft, 1 = direct drive)
ke = 1.019 # Back-EMF constant (V·s/rad)
kt = 0.882 # Motor torque constant (N·m/A)
R = 0.46 # Motor winding resistance (Ω)
B = 0.049 # Motor viscous damping at wheel shaft (N·m·s/rad)

Calculations

Body inertia about lean pivot
I1_pivot = I1_cm = 1.15m1L1² = 1.15 × 12 × 0.52² = 3.732 kgm²

RW inertia about lean pivot
I2_pivot = J + m2L2² = 0.03126 + 5 × 0.22² = 0.273 kgm²

Combined system inertia
I_total = I1_pivot + I2_pivot = 3.732 + 0.273 = 4.005 kgm²

At θ = 5 degrees = 0.08727 rad

Torque from bicycle body mass
τ_grav1 = m1gL1sin(θ) = 12 × 9.81 × 0.52 × 0.08727 = 5.342 Nm

Torque from RW
τ_grav2 = m2gL2sin(θ) = 5 × 9.81 × 0.22 × 0.08727 = 0.942 Nm

Total gravitational tipping torque
τ_grav = τ_grav1 + τ_grav2 = 5.342 + 0.942 = 6.283 Nm

Equation of Motion
τ_rw = τ_grav − dpθp' − I_total p'' where p'' is the desired angular acceleration. A negative value drives the bicycle back toward upright.

Damping term at arrest moment:
θ̇p (estimated) = ~0.15 rad/s (falling from rest over ~0.3 s)
dpθp' = 0.01 × 0.15 = 0.0015 Nm (Negligible)

Active recovery (θp'' = −0.50 rad/s²)
I_totalθp'' = −4.005 × (−0.50) = +2.002 Nm
τ_rw = τ_grav − dpθp' − I_total p'' = 6.283 + 2.002 = 8.285 Nm

Gross Motor Torque
τ_{motor gross} = τ_{rw_net} + Bωr = 8.285 + 0.049 × 50 = 10.735 Nm

Appendix C: Control System Parameters

1. LQR Computation

The computation follows a structured sequence:

Definition of physical parameters
Construction of the state-space model
Controllability and Observability
Weight Selection and Gain Computation
Stability Verification and Control Authority
Deployment to ESP32

Definition of physical parameters

The computation begins with the definition of all relevant physical parameters describing the system, forming the basis for deriving the system dynamics and directly influencing the resulting control gains.

Construction of the state-space model

The system matrices A and B were assembled from the physical parameters of the bicycle and motor. Three intermediate quantities are first derived:

where a is the total lean inertia about the tyre contact pivot, b is the gravitational torque coefficient, and c_m is the combined motor damping term.

These are then used to populate the individual matrix entries before being assembled into the full A and B matrices.

Controllability and Observability

Before solving for the gains, the script verifies the system is controllable and observable:

A controllability rank of 4 confirms all states can be driven by V_in. The observability check uses C = [1 0 0 0, 0 1 0 0], reflecting that only lean angle and lean rate are measured directly by the IMU while the wheel states are not directly sensed. If controllability fails, the script raises a fatal error and aborts, preventing deployment of an invalid gain vector.

Weight Selection and Gain Computation

The weighting matrices were defined as:

The lean angle carries the highest penalty Q₁₁=100 as it is the primary stabilisation objective. The lean rate is penalised at Q₂₂=50 for adequate damping, and the wheel velocity at Q₄₄=10 to limit momentum saturation. The wheel angle is given a low weight of Q₃₃=1, nonzero only to prevent unbounded winding of the wheel over time. The input penalty R=100 was sized to keep V_in within the 48 V supply rail under normal operating conditions.

The gains are then computed in a single call:

which solves the ARE and returns the optimal gain row vector K=[₀₀, K₀₁, K₀₂, K₀₃], the solution matrix S, and the closed-loop eigenvalues E. Each gain represents the contribution of its respective state to the control input. The resulting control law is implemented as a linear combination of the system states.

Stability Verification and Control Authority

The script computes the closed-loop poles from A_cl=A−BK and checks that all real parts are strictly negative. It also performs a control authority check at a representative worst-case condition:

This evaluates the demanded voltage at a 3 degree lean with a 5 degree/s lean rate. If max_V_in exceeds the 48 V supply, the script warns that R should be increased or the Q weights reduced before deployment.

Deployment to ESP32

The four gains are extracted and formatted as C preprocessor constants:

The control law is implemented in real time as:

This equation generates the motor command required to stabilise the system based on current state measurements, and will be explained in further detail in the next section.

Appendix D: Hardware Schematics

Motor Specifications

Motor Controller Specifications

Appendix E: Firmware Architecture

Detailed Code Architecture

Simple movement commands on arduino to see what commands the controller responded to.
Added more complex bidirectional commands to test motor and controller responsiveness and limits. Motor cut out when directional changes were too frequent (< 0.2s), prone to skipping the subsequent commands and restarting loops
Added in delays to try to fix the issue, limited effectiveness
Upgraded controller, better responsiveness. Implemented simple PID on arduino mega
Upgraded to stm32, implemented more complex pid
stm32 ide was too complex to code on, changed to esp32 to not waste time on learning stm32
Implemented LQR on esp32 with mahony and butterworth filter
Added hysteresis function to smoothen motor
Changed to current control instead of voltage control to access torque control
Calibrating LQR gains via python code
Calculated optimal K matrix gains by accounting for physical params and Q and R matricesr

Section 1: System Configuration

This stage configures the hardware connections, component parameters and system variables. These include the motor parameters and polarity (PWM, Brake, Reverse), PWM control, Brake control, control loop frequency, MPU6050 parameters, hall-sensor parameters, LQR gains, system thresholds and debugging variables.

Section 2: Hardware Helper Functions (Motor, IMU, Hall Sensor)

This stage comprises various function definitions pertaining to the prototype’s hardware systems. This includes:

Motor Control: establishing motor direction (forward/reverse), brake (on/off) and PWM control.
IMU Subsystem: definition and configuration of key MPU6050 functions and parameters, including axis definition, IMU calibration and a 1st-order complementary filter to fuse high-frequency gyroscope data with low-frequency accelerometer data to obtain values utilised in the LQR algorithm later. IMU is also updated every control loop for regular system re-calibration.
Hall Subsystem: provides the HL6SD motor’s angular velocity parameter values, which is used in conjunction with the IMU values measuring the bike frame’s angular tilt and angular velocity (rate of change of angular tilt) for the LQR control algorithm.

Section 3: LQR Control Algorithm

The LQR algorithm implements full-state linear feedback for the linearised dynamic model of the bike-RW system, as illustrated in Section 4.3.2. This algorithm utilises the LQR gain coefficients computed in Section 5.5.1.

Section 4: AQMD Controller Output

The applyDutyCommand() function translates the LQR's signed voltage command into a PWM duty cycle and motor direction, which is then applied to the HL6SD motor.

Section 5 & 6: Setup & Control Loop

This section comprises system initialisation and the main control loop for the program. The control loop’s workflow is illustrated in Figure 16.

Code Summary:

The overall control software for the RW balancing module is organized as a layered real-time closed-loop system. The ESP32-S3 microcontroller acquires body tilt and tilt-rate information from an MPU6050 IMU and RW rotational speed from hall sensors embedded in the HL6SD motor. These measured states are filtered and validated before being passed to an LQR-based controller, which computes the motor effort required to oppose the bicycle’s lean. The computed command is then translated into PWM, direction, and braking signals for the AQMD6020BLS motor controller through a dedicated actuator-management layer that handles reversal braking, PWM ramping, and safety cutoffs. Additional I²C recovery and IMU fault-handling routines improve robustness under motor-induced electrical disturbance. Collectively, these software sections enable the RW to generate reaction torque in the correct direction and with sufficient speed to help restore the bicycle toward upright equilibrium.

Appendix F: Testing Data

Phase 1: K-matrix Gains test

Initial values:

LQR_SCALE_FACTOR = 1.0
PWM_STEP = 2
PWM_MIN_RUN = 1

Steps:

Set a conservative R value (1000) and the default Q matrix. Compute the K matrix offline in Python using the control library and flash the gains to firmware.
Hold the bicycle upright near equilibrium and release it.
If the system is stable: decrease R by one order of magnitude and repeat from Step 2.
If overcurrent warnings or I2C bus crashes occur: the gains are too aggressive for the current hardware limits. Revert to the previous R value and record it as the fault threshold.
Stop once the highest R (lowest gain) that produces observable corrective action and the lowest R (highest gain) before faults occur have both been identified. Select the operating point with the best balance of responsiveness and stability as the candidate K matrix for Phase 2 onwards.

Phase 1: K-matrix Gains test results

Phase 1: Additional K-matrix gains test (Vary Q[3,3])

Goal

Identify a set of LQR weighting matrices Q and R that yields K-matrix gains capable of stabilising the bicycle without saturating the motor driver or inducing I2C bus faults.

Initial values:

LQR_SCALE_FACTOR = 1.0
PWM_STEP = 2
PWM_MIN_RUN = 1

Steps:

Set a conservative Q[3,3] value (100) and the chosen R matrix. Compute the K matrix offline in Python using the control library and flash the gains to firmware.
Hold the bicycle upright near equilibrium and release it.
If the system is stable: decrease Q[3,3] by one order of magnitude and repeat from Step 2.
If overcurrent warnings or I2C bus crashes occur: the gains are too aggressive for the current hardware limits. Revert to the previous Q[3,3] value and record it as the fault threshold.
Stop once the highest Q[3,3] that produces observable corrective action and the lowest Q[3,3] before faults occur have both been identified. Select the operating point with the best balance of responsiveness and stability as the candidate K matrix for Phase 2 onwards.

Phase 2: Tuning ‘PWM_MIN_RUN’

Goal

Determine the minimum PWM duty below which the motor stalls rather than rotates, and set PWM_MIN_RUN to eliminate this deadband.

Initial values:

LQR_SCALE_FACTOR = 0.1
PWM_STEP = 2
PWM_MIN_RUN = 10

Steps:

Holding the bicycle upright, slowly lean it back and forth to trigger small LQR corrections.
Observe motor for rotation.
If motor does not move, increase PWM_MIN_RUN by 10.
If motor moves, reduce by 10.
Stop when the smallest tilt causes the motor to start rotating smoothly.

Goal

Phase 3: Finding the EMI Limit (Tuning ‘PWM_STEP’)

Steps:

Set LQR_SCALE_FACTOR to 1.0 so the controller demands aggressive movements.
Hold the bicycle and deliberately tilt it left and right quickly (5-10 degrees) to force the motor to rapidly reverse direction. Do it for 5 consecutive reversals.
If the I2C bus crashes, decrease PWM_STEP by 1.
If the I2C stays stable: Increase PWM_STEP by 1 and repeat the shaking test.
Stop once the exact PWM_STEP that causes an I2C failure is found. Take the previous value for safety margin.

Phase 3: PWM_STEP test results

Phase 4: Controller Authority (Tuning ‘LQR_SCALE_FACTOR’)

Steps:

Keeping PWM_MIN_RUN and PWM_STEP at their new values, reset LQR_SCALE_FACTOR to 0.1.
Allow the bicycle to attempt to balance by momentarily letting go of it near equilibrium.
If the bicycle falls over: The controller is too weak. Increase by 0.1.
If the bicycle catches itself but falls: Increase slightly by 0.05.
If the controller detects overcurrent or I2C bus crash: Decrease by 0.05.
Validation: The optimal value is the highest possible number just before the bicycle starts vibrating while standing still.

Phase 4: LQR_SCALE_FACTOR test results

Phase 5: System Braking (Tuning ‘REVERSE_BRAKE_HOLD_MS’)

Steps:

Set LQR_SCALE_FACTOR, PWM_MIN_RUN and PWM_STEP at their final values.
Start with REVERSE_BRAKE_HOLD_MS = 100. Hold the bicycle upright and deliberately apply 10 degree tilts in quick alternation to force repeated direction reversals. Do it for 5 consecutive reversals.
Watch the Serial monitor I2C warnings during the reversal window.
If no overcurrent and I2C warnings: decrease REVERSE_BRAKE_HOLD_MS by 50 ms and repeat.
If there is overcurrent warning or I2C bus crashes: Increase by 50 ms and accept the previous value.
Stop condition: The final value is the lowest REVERSE_BRAKE_HOLD_MS where the motor consistently brakes across 5 consecutive reversals without triggering overcurrent or crash I2C bus.

Phase 5: REVERSE_BRAKE_HOLD_MS test results

Appendix G: Project Timeline

Prototyping Timeline: AY25/26 Semester 2 (12 Jan 26 - 17 Apr 26)

Week 1: Meeting with supervisor

Recap of Project details (objectives, evaluation of work done in sem 1)
Preliminary Ideation of Design Mechanism (Reaction-Wheel)
Preliminary Sourcing of Design Components
Aim to minimise costs by utilising materials immediately available to us (HL6SD Motor, MX25 Motor Controller, Arduino Uno/Mega)
Organised Research topics and chart project direction

Week 2: Familiarising ourselves with components

Attempted to connect 1st motor setup (motor + controller + Uno + Power supply) to ascertain motor performance
Programmed/Reset MX25 Controller parameter values via MX25-DC configuration software.
Preliminary Observations: Motor was slow but managed to move

Week 3: Identifying aspects of setup to modify/replace to enhance self-balancing module performance

Secondary Sourcing of different motors + controllers
Motor: Sourced for alternative hub motors (motors with external drive shafts or gearboxes would be inadequate for the rate of directional-change we require for this balancing module)
Controller: Sourced for alternative torque-based motor controllers for higher performance
Code Development and Integration of IMU Sensor (MPU6050) into system

Week 4: 1st Proof-of-Concept (POC) of System Functionality

Ascertained that motor was able to perform direction-change according to tilt angle measured by MPU6050.
Established fundamental logic, control algorithm (PID) and skeleton structure of system code
Evaluated system performance and determined need for further sourcing for more capable component alternatives

Week 5: Improving System Performance

Substituted Arduino Uno with Mega 2560 (more GPIO pin connections available)
Added Mahony and Butterworth Filters to code (as used in our RC-bike prototype in Sem 1)
Added Resistor Dividers for Hall Sensor Wires (Step-Down 5V to 3.3V)
Submitted claim for new motor controller (AQMD6020BLS)
Enhanced PID control algorithm (refined coefficient-values)

Week 6: Improving System Performance

Received AQMD Controller and conducted preliminary setup (parameter values)
Replaced MX25 with AQMD controller in setup
Procured STM32F407VGT6 MCU from IDP Workshop for enhanced processing power
Substituted LQR for PID in code program for greater reaction speed and more precise control
Procured full-size bicycle frame for final prototype
Tested AQMD Controller in Duty-Cycle mode (with Mega first, then STM32)

Recess Week: Improving System Performance

Attempted to setup and integrate STM32 into existing setup
Due to time constraints amid difficulty of configuring and integrating STM32 into setup via STM32CubeIDE, which necessitated significant reformatting changes to the existing code structure, we decided to forego STM32 and select ESP32 as the optimal MCU (strike balance between processing power and ease of programming/use)
Designed and 3D-printed motor mount to bicycle (with help from Supervisor)
Tested AQMD Controller in Torque-mode with ESP32

Week 7: Refining code

Added torque/tilt hysteresis functionality to code to minimise jitters during testing
Confirmed 1st draft of final code program for system

Week 8: Troubleshooting and Reaction-wheel Assembly

Attempted to tune parameter values to adjust the motor's reaction speed (for directional-change), torque (i.e. acceleration; rate of PWM ramping) and jitters (via hysteresis)
However, during testing on Tuesday, the physical test setup (electronics section) was accidentally dropped from a height, causing some wiring to fall out of the controller and esp32 and causing the system to fail. After this incident, our test code no longer worked and the motor no longer functioned properly, leading us to perform urgent troubleshooting and relook the entire setup (choice of MCU; choice of AQMD operating mode; wiring and signal integrity, code logic; hardware vs software failure nodes)
On Friday, troubleshooting was still unsuccessful, so due to time constraints, we chose to modify the physical motor setup by affixing weights (bolts) to the motor to enhance torque.

Week 9: Debugging and Troubleshooting 1

Mon: Stripped system down to bare basics to determine causes of failure with each component. Swapped out ESP32 with Arduino Mega and ran old code. System did not work; but identified that MPU6050 was operating erratically, so went to IDP Workshop to procure new MPU6050, breadboard and jumper cables.
Wed: Continued troubleshooting diagnosis; Ran 6 different codes for different stages of the prototyping process. NOTE: Non-core features like filters and hysteresis were removed to facilitate error identification in firmware.
Fri: Finalise Physical Prototype Setup (load everything onto bicycle); Attempted adding brake functions to code.
Started writing draft for final report

Week 10: Debugging and Troubleshooting 2, Testing 1

Tues: Modified code to prevent corruption of IMU due to parameter values and system initialisation. Aim to test key parameter values (LQR_SCALE_FACTOR) and effect on system
Wed: Validated final code template. Tuned 3 main parameters to assess their effects on the system and identify optimal values for each.
Fri: Completed refining and parameter-tuning process. Code finalised for existing iteration of physical setup.

Week 11: Testing 2

Report writing
Wed: Validated final code template. Tuned 3 main parameters to assess their effects on the system and identify optimal values for each.
Fri: Completed refining and parameter-tuning process. Code finalised for existing iteration of physical setup.

Week 12: Report Submission

Week 13: Presentation and Showcase

References

[1] Verified Market Research. (2025, February). Asia-Pacific Electric Two-wheeler market size, and forecast. Asia-Pacific Electric Two-Wheeler Market Size By Propulsion Type (Hybrid, Electric Vehicles), By Vehicle Type (Electric Scooters, Electric Motorcycles), By Application (Personal Use, Commercial Use), By Geographic Scope And Forecast. https://www.verifiedmarketresearch.com/product/asia-pacific-electric-two-wheeler-market/
[2] Phan, The & Pham, Chau & Pham, Cong Bang. (2024). Study and Implementation of Self-Balancing Electric Motorcycle. https://www.researchgate.net/publication/387079285_Study_and_Implementation_of_Self-Balancing_Electric_Motorcycle
[3] A. N. Hidayati and U. Wasiwitono, "Modeling and Control of Inertia Wheel Pendulum System with LQR and PID control," 2021 International Seminar on Intelligent Technology and Its Applications (ISITIA), Surabaya, Indonesia, 2021, pp. 135-140, doi: 10.1109/ISITIA52817.2021.9502267
[4] I. I. Siller-Alcalá, J. U. Liceaga-Castro, R. A. Alcántara-Ramírez, and S. Calzadilla-Ayala, “Using a Flywheel to Stabilize a Self-Balancing Bicycle,” WSEAS TRANSACTIONS ON SYSTEMS AND CONTROL, vol. 19, pp. 73–84, Apr. 2024, doi: https://doi.org/10.37394/23203.2024.19.8.
[5] Gunnar, “Inverted Pendulum + Reaction Wheel = Autonomous Stabilized Bicycle,” YouTube, Mar. 15, 2012. https://www.youtube.com/watch?v=EAhQyBLxgu4 (accessed Apr. 02, 2026).
[6] “Tonino Lamborghini 2724667071453 Folding Bicycle with 18-Speed Alloy V-Brake (20in): Buy Online at Best Price in Egypt - Souq is now Amazon.eg,” Amazon.eg, 2026. https://www.amazon.eg/-/en/Lamborghini-2724667071453-Folding-Bicycle-18-Speed/dp/B09BDNBSY6 (accessed Apr. 02, 2026).
[7] Engwe.com, 2026. https://engwe.com/blogs/news/comparison-of-e-bike-motors (accessed Apr. 02, 2026).
[8] “Electric Bike Motors Explained: Types, Benefits & How to Choose the Right One,” Electronicsaviors, Oct. 23, 2025. https://electronicsaviors.com/electric-bike-motors/ (accessed Apr. 02, 2026).
[9] “6 inch hub motor disc brake geared slow speed,” uumotor, Oct. 25, 2019. https://www.uumotor.com/6-inch-hub-motor-disc-brake-geared-slow-speed.html (accessed Apr. 02, 2026).
[10] “Mid-Drive vs. Hub: A Guide to Different E-Bike Motor Options,” Velotric, Jan. 25, 2023. https://www.velotricbike.com/blogs/story-landing/guide-to-e-bike-motors
[11] “25A 24V-48V universal emb bldc motor controller,” uumotor, Nov. 18, 2018. https://www.uumotor.com/25a-24v-48v-universal-emb-bldc-motor-controller.html (accessed Apr. 02, 2026).
[12] “AQMD6020BLS-E2F直流无刷电机驱动器 - FOC系列 - 艾思控®成都爱控电子科技有限公司,” Akelc.com, 2021. http://www.akelc.com/Product/BLDC-Motor-Driver/FOC/a32.html (accessed Apr. 02, 2026).
[13] “Arduino® MEGA 2560 Rev3.” Available: https://docs.arduino.cc/resources/datasheets/A000067-datasheet.pdf
[14] “STM32F405xx STM32F407xx.” Available: https://www.st.com/resource/en/datasheet/dm00037051.pdf
[15] “ESP32-S3-DevKitC-1 v1.1 - ESP32-S3 - — esp-dev-kits latest documentation,” Espressif.com, 2016. https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32s3/esp32-s3-devkitc-1/user_guide_v1.1.html
[16] “MPU-6000 and MPU-6050 Register Map and Descriptions Revision 4.0 MPU-6000/MPU-6050 Register Map and Descriptions,” 2012. Available: https://cdn.sparkfun.com/datasheets/Sensors/Accelerometers/RM-MPU-6000A.pdf
[18] Jaka P. Sembiring, Ahmad Amirudin, Novia Utami Putri, Danur Wijayanto; Steering control of a self-balancing bicycle. AIP Conf. Proc. 9 April 2024; 3109 (1): 040001. https://doi.org/10.1063/5.0204905
[19] Wang, Y., Bruzelius, F., Sjöberg, J. (2024). Gain-Scheduled Bicycle Balance Controller Based on System Identification. In: Mastinu, G., Braghin, F., Cheli, F., Corno, M., Savaresi, S.M. (eds) 16th International Symposium on Advanced Vehicle Control. AVEC 2024. Lecture Notes in Mechanical Engineering. Springer, Cham. https://doi.org/10.1007/978-3-031-70392-8_96
[20] N. C. Sanchez, L. A. Pastor and K. Larson, "Autonomous Bicycles: A New Approach To Bicycle-Sharing Systems," 2020 IEEE 23rd International Conference on Intelligent Transportation Systems (ITSC), Rhodes, Greece, 2020, pp. 1-6, doi: 10.1109/ITSC45102.2020.9294332.

CDE4301 Innovation & Design Capstone

AY2025-2026 Semester 2

Final Report

Project Code: FTS-403 (Self-Balancing Bike)

Submitted by

Project Supervisor

Industry Partner

Table of Contents

Acknowledgements

Project Supervisor:

Industry Partner:

List of Acronyms

1. Introduction

1.1 E2W Market

1.2 Industry Partner: Red Dot Mobility

2. Problem Definition and Objectives

2.3 Problem Statement

3. Value Proposition

3.1 Value Proposition Canvas

4. Design Methdology and Concept Development

4.1 Design Statement

4.2 Design Solution

4.2.1 IWP Model

4.2.2 Linear Quadratic Regulator

4.2.3 1st Prototype (RC-Bike)

5. Prototyping

5.1 Prototype Design Overview

5.1.1 Technical Requirements and System Objectives

5.1.2 Bill-of-Materials (BOM)

5.2 Mechanical System

5.2.1 Frame and Structural Components

5.2.2 Reaction Wheel Module (Assembly and Components)

5.3 Electrical System Implementation

5.3.1 Motor Controller Selection

5.3.2 Power System Design

5.4 Embedded System Development

5.4.1 Microcontroller (MCU) Selection

5.4.2 Sensor Integration

5.4.3 Firmware Development

5.5 Software and Code Architecture

5.5.1 LQR Computation

5.5.2 Code Architecture

5.6 Iterative Prototype Development

6. Testing and Experimental Setup

6.1 Objectives and Scope of Testing

6.2 Experimental Setup

6.2.1 Mechanical Configuration

6.2.2 Electronics and Integration

6.2.3 Stabilisation and Safety Measures

6.2.4 Testing Environment

6.3 Testing Methodology

6.4 Prototype Testing Procedures

6.4.1 Phase 1: K-matrix Gains Test

6.4.2 Phase 2: Tuning ‘PWM_MIN_RUN’

6.4.3 Phase 3: Finding the EMI Limit (Tuning ‘PWM_STEP’)

6.4.4 Phase 4: Controller Authority (Tuning ‘LQR_SCALE_FACTOR’)

6.4.5 Phase 5: Reversal Braking Timing (Tuning 'REVERSE_BRAKE_HOLD_MS')

7. Results and Analysis

7.1 Data Collection and Processing

7.2 System Performance Analysis and Evaluation

7.2.1 Tuned Parameter Summary

7.2.2 Phase 1: LQR Gain Matrix (K-Matrix) Selection

7.2.3 Phase 2: Motor Deadband Elimination (PWM_MIN_RUN)

7.2.4 Phase 3: EMI Threshold Identification (PWM_STEP)

7.2.5 Phase 4: Controller Authority (LQR_SCALE_FACTOR)

7.2.4 Phase 5: System Stability (REVERSE_BRAKE_HOLD_MS)

7.3 Discussion of Observed Trends

7.3.1 Trend 1: Overcurrent during rapid reversals

7.3.2 Trend 2: I2C bus crash due to EMI overload

7.3.3 Trend 3: IMU and I2C Bus Lag Under Motor Excitation

7.4 Comparison with Theoretical Predictions

8. Fulfilment of Deliverables

8.1 Intended Project Deliverables

8.2 Achieved Outcomes

8.3 Evaluation of Project Success

9. Limitations and Recommendations for Future Work

9.1 Identified Limitations and Justifications

9.1.1 Simplified Dynamic Model

9.1.2 Reaction Wheel Moment of Inertia

9.2 Technical Challenges Encountered