Lab 12: Inverted Pendulum

2026-05-13T00:00:00+00:00

Overview</h1>
I drew inspiration from two prior writeups — Aravind Ramaswami's wheelie report</a> (Kalman + pole-placement) and Stephan Wagner's Lab 12 report</a> (hand-tuned PD, no observer). With Dyllan Hofflich and Tina Cheng, our final solution lands closer to Stephan's.</p>
The inverted pendulum is a very famous unstable nonlinear system — a small disturbance from vertical grows exponentially unless the controller can inject a corrective force faster than the car falls. On our hardware the fall-time constant is about 70 ms, which sets a hard lower bound on the control loop rate. The lab broke into three pieces: model the car as a pendulum on a cart, build a real-time balance controller at $\theta = 0$, and add a launch state machine to flip the car up from horizontal.</p>

Pendulum-on-cart geometry</h3>
A wheel of mass $M$ translates along $x$, with a rigid rod of mass $m$ and moment of inertia $I$ attached to its axle. The rod's COM is a distance $\ell$ above the wheel center. State vector:</p>
$$ \mathbf{x} = \begin{bmatrix} x \ \dot x \ \theta \ \dot\theta \end{bmatrix}. $$</p>
</p>

Lagrangian and equations of motion</h3>
With $T_w = \tfrac{1}{2}M\dot x^2$, $T_p = \tfrac{1}{2}m,[(\dot x + \ell\dot\theta\cos\theta)^2 + (\ell\dot\theta\sin\theta)^2] + \tfrac{1}{2}I\dot\theta^2$, and $V = mg\ell\cos\theta$, the Lagrangian $\mathcal{L} = T_w + T_p - V$ gives:</p>
$$ (M + m),\ddot x + m\ell,\ddot\theta\cos\theta - m\ell,\dot\theta^2\sin\theta = u $$ $$ (I + m\ell^2),\ddot\theta + m\ell,\ddot x\cos\theta - mg\ell\sin\theta = 0 $$</p>

Linearization about vertical</h3>
Substituting $\sin\theta \approx \theta$, $\cos\theta \approx 1$, $\dot\theta^2 \approx 0$ linearizes the coupled equations around the upright equilibrium. Since the car has no wheel encoder and I can't ready the cart's absolute position, I drop the $x$ row entirely — penalizing $x$ in $Q$ wouldn't actually make the controller know where the cart is. The reduced 2-state model in $[\theta,\ \dot\theta]$ becomes:</p>
$$ \dot{\mathbf{x}} = A\mathbf{x} + B u, \quad A = \begin{bmatrix} 0 & 1 \ \alpha_1 & 0 \end{bmatrix}, \quad B = \begin{bmatrix} 0 \ \alpha_2 \end{bmatrix} $$</p>
with $\alpha_1, \alpha_2$ aggregating $g$, $\ell$, $m$, $M$, $I$. The positive entry $\alpha_1$ on the off-diagonal is what makes the upright equilibrium unstable — its square root is the divergent eigenvalue of $A$, the reciprocal of the fall-time constant. I initialize $\alpha_1 \approx 6.21$, $\alpha_2 \approx 60$ from Aravind's report as a starting point.
I will retune the constants by hands later.</p>

Controller Design</h2>

LQR produces gains that optimally trade off state error against control effort. The cost $J = \int_0^\infty \mathbf{x}^\top Q,\mathbf{x} + R u^2, dt$ gives optimal feedback $K = R^{-1} B^\top P$, where $P$ solves the continuous-time algebraic Riccati equation:</p>

$$ A^\top P + P A - P B R^{-1} B^\top P + Q = 0. $$</p>

I weighted $Q$ heavily on $\theta$ (100) and lightly on $\dot\theta$ (1), with $R = 1$ — penalize pose error, tolerate motion, don't over-penalize the motor:</p>

import</span> numpy</span> as</span> np</span></span>
from</span> scipy.linalg</span> import</span> solve_continuous_are</span></span>
</span>
A</span> =</span> np.array([[</span>0</span>,</span> 1</span>], [</span>6.21</span>,</span> 0</span>]])</span></span>
B</span> =</span> np.array([[</span>0</span>], [</span>60.0</span>]])</span></span>
Q</span> =</span> np.diag([</span>100.0</span>,</span> 1.0</span>])</span></span>
R</span> =</span> np.array([[</span>1.0</span>]])</span></span>
</span>
P</span> =</span> solve_continuous_are(A, B, Q, R)</span></span>
K</span> =</span> np.linalg.inv(R)</span> @</span> B.T</span> @</span> P</span></span>
print</span>(</span>"LQR gains [Kp, Kd]:"</span>, K.ravel())</span></span></code></pre>
Result: $K_p \approx 0.04$, $K_d \approx 0.005$</p>
Why PD with hand-tuned gains in the end</h3>
The LQR output assumes the control input is in Newtons, but my firmware
issues signed PWM (−255 to +255). Converting between them requires a
force-to-PWM constant $k_f$ that I never measured, which left my LQR
gains dimensionally inconsistent with the motor command. I converged on
PD gains by hand instead, using the LQR ratio of $K_p:K_d$ as a starting
point:</p>
Parameter</th> Value</th> Why</th></tr></thead>

$K_p$</td> 15.0</td> 5° error → 75 PWM, above motor deadband</td></tr>
$K_d$</td> 1.0</td> Rate damping to avoid oscillation</td></tr>
max pwm</td> 255</td> Full authority for large disturbances</td></tr>
target pitch</td> +90°</td> Wheelie orientation in my IMU mounting</td></tr>
</tbody></table>
The reference's $K_p = 4$, $K_d = 0.2$ were sub-deadband: 5° → 20 PWM
didn't move the wheels at all, then larger errors slammed past — a
limit-cycle recipe. Tripling $K_p$ moved every meaningful correction
above the motor's static-friction threshold.</p>
Control law in firmware</h3>
if</span> (stunt_state </span>==</span> IPEND_HOLD) {</span></span>
    float</span> pitch_rate_dps </span>= +</span>latest_gx;</span></span>
    float</span> deviation      </span>=</span> latest_pitch_comp </span>-</span> ipend_cfg.target_pitch_deg;</span></span>
    float</span> u              </span>=</span> ipend_cfg.Kp</span> *</span> deviation</span></span>
                         +</span> ipend_cfg.Kd</span> *</span> pitch_rate_dps;</span></span>
    int</span>   pwm            </span>=</span> (</span>int</span>)</span>constrain</span>(u,</span> -</span>ipend_cfg.max_pwm,</span></span>
                                              +</span>ipend_cfg.max_pwm);</span></span>
    setLeftMotor</span>(pwm);</span></span>
    setRightMotor</span>(pwm);</span></span>
}</span></span></code></pre>
Both wheels get the same signed PWM — no differential needed.</p>
IMU State Estimation</h2>
I tried Aravind's Kalman observer first, but the estimate drifted
unpredictably during fast maneuvers — translational acceleration from
the cart kept contaminating the accelerometer pitch, the filter couldn't
distinguish it from a true tilt, and the controller would saturate on
phantom angles. After a couple of sessions tuning $\Sigma_u$ and
$\Sigma_z$ to no avail, I went back to the complementary filter I
already used in earlier labs:</p>
pitch_lpf_state </span>=</span> ALPHA_LPF </span>*</span> pitch_acc </span>+</span> (</span>1</span> -</span> ALPHA_LPF)</span> *</span> pitch_lpf_state;</span></span>
pitch_comp_state </span>=</span> (</span>1</span> -</span> ALPHA_COMP)</span> *</span> (pitch_comp_state </span>+</span> pitch_rate </span>*</span> dt)</span></span>
                 +</span> ALPHA_COMP </span>*</span> pitch_lpf_state;</span></span></code></pre>
The intuition is that the gyro is accurate on short timescales but drifts
when integrated; the accelerometer is noisy on short timescales but
absolute on long ones. With ALPHA_LPF = 0.10</code> and ALPHA_COMP = 0.05</code>,
the filter trusts the gyro between frames and gently pulls toward the
accel pitch over hundreds of milliseconds. At 50 Hz this is essentially
as good as Kalman, with zero hyperparameters to retune per stunt.</p>
Axis-swap calibration</h3>
My IMU was mounted rotated 90° about the car z-axis, so car pitch
showed up on IMU-y instead of IMU-x. I verified this by walking the car
through five orientations and noting which accel channel saturated to ±1 g in each. Fixed by
swapping which axes feed pitch and roll:</p>
latest_pitch_acc </span>=</span> atan2</span>(latest_ay, latest_az)</span> *</span> 180.0</span>f /</span> M_PI;</span></span>
latest_roll_acc  </span>=</span> atan2</span>(latest_ax, latest_az)</span> *</span> 180.0</span>f /</span> M_PI;</span></span>
float</span> pitch_rate </span>= +</span>latest_gx;</span></span></code></pre>Switching Cars + Tuning</h2>
After days of fighting motor deadband and surface friction on my own car,
I switch to path planning on the last day to have a complete
deliverable. Coming back to the pendulum with Dyllan and Tina, we ran my PD
code on Dyllan's car and it balanced for a couple of seconds, my controller was actually decent for Ananya's car.
We then committed to Dyllan's full LQR formulation and tuned it together; the results below come from his
car. Ultimately, it came down to whose code seemed to have a better balance results because what it is left was just tuning, and it seems like his code just provided a better starting point</p>
Wheelie Launch State Machine - Attempt</h2>
The launch sequence: drive forward to build
linear momentum, brake hard to plant the front wheels, then reverse the
motors. The wheels yank the contact point backward while the car's
inertia keeps it moving forward, and the mismatch generates a
forward-pitching torque about the front axle that lifts the rear into
a wheelie. Once $|\theta| > 30°$, the FSM hands off to the balance
controller. The FSM has one interesting state (BALANCE</code>); everything
else is event-driven timing, with timeouts dropping back to IDLE</code> if
the launch fails.</p>
struct</span> WheelieConfig</span> {</span></span>
    int</span>   forward_pwm        </span>=</span> 250</span>;</span></span>
    int</span>   forward_ms         </span>=</span> 250</span>;</span></span>
    int</span>   brake_ms           </span>=</span> 100</span>;</span></span>
    int</span>   reverse_pwm        </span>=</span> 250</span>;</span></span>
    int</span>   reverse_ms         </span>=</span> 270</span>;</span></span>
    int</span>   wait_max_ms        </span>=</span> 600</span>;</span></span>
    float</span> balance_trigger_deg </span>=</span> 30.0</span>f</span>;</span></span>
    float</span> target_pitch_deg    </span>= +</span>90.0</span>f</span>;</span></span>
    float</span> Kp </span>=</span> 15.0</span>f</span>;</span></span>
    float</span> Kd </span>=</span> 1.0</span>f</span>;</span></span>
    int</span>   max_balance_pwm </span>=</span> 255</span>;</span></span>
};</span></span></code></pre>Results</h2>
My best controller</h3>
Here's what my best inverted pendulum on Ananya's car. This is purely the code I developed on my own.</p>
</iframe>
First attempt</h3>
We found that the performance of the controller with the initial gain matrix was pretty bad, with the robot oscillating a lot and not being able to balance for more than a second if at all.</p>
</iframe>
After tuning</h3>
Instead of trying to tune the Q and R matrices to get a better gain matrix, we decided to just manually tune the gain matrix by hand.</p>
</iframe>
PID solution</h3>
After struggling to get the LQR controller to work well, we attempted to implement a PID controller on a linearized system. It is a simple PID controller using the angle error from the DMP readings, we thought we had more experience tuning it from previous labs, but it just performed worse.</p>
</iframe>
Launch attempts</h3>
Two attempts at the full launch-to-balance logic. The launch FSM
reaches the trigger threshold, but the dynamic was super noisy, and our balance controller cannot handle it very well.</p>
</iframe>
</iframe>
Surface comparison: wood vs. carpet</h3>
Surface friction matters more than I expected. On wood the wheels
slip during accelerations, so the controller cannot change fast enough, and the car tends to be less stable. On carpet the wheels bite and the controller's
output actually moves the cart, which is what makes balance sustainable.</p>
Best result on wood:</strong></p>
</iframe>
Best results on carpet:</strong></p>
</iframe>
</iframe>
Final results — with weight on top</h3>
The breakthrough was taping weights to the top of the chassis(with some further tuning of course). The
higher $I_{b,\text{com}}$ lengthens the fall-time constant, which
gives the controller more headroom to react to each disturbance.
The pole has a much better stability. See the final
clips at the bottom of
Dyllan's Lab 12 report</a>
for the best runs of the tuned LQR with weight added.</p>
Bonus Videos & Bloopers</h2>
Some of the more failures and side experiments from the
tuning sessions.</p>
</iframe>
</iframe>
</iframe>
</iframe>
</iframe>
</iframe>
</iframe>
Tangent: Path Planning</h2>
Overview of path planning. I worked on this for about six hours before joining Dyllan and Tina on
the Inverted Pendulum. The task is to
navigate 9 waypoints across the mapped arena, from $(-4, -3)$ to $(0, 0)$
in grid cells. I went with turn-go-turn between adjacent waypoints
(no global planning — the waypoints are hand-designed and have no walls
between consecutive points) and a Bayes-filter update at every
waypoint, reusing the Lab 11 pattern: uniform-prior reset before each
360° scan, no prediction step (the provided $O(N^6)$ implementation is
too slow for online use). Onboard PID handles both the in-place turn and
the ToF-based straight leg; offboard Python plans the segments and
await</code>s DONE</code> notifications from the firmware so the Bayes-filter
compute doesn't compete with the 50 Hz control loop. A single waypoint
takes 8–12 seconds end-to-end, dominated by the 18
turn-and-settle cycles of the localization scan. My best run hits the
first 4–5 waypoints before cumulative heading drift (±5° per turn) points
the car at a wall.</p>
async def</span> step_once</span>(self):</span></span>
    # 1. Current pose = argmax of latest belief</span></span>
    cell</span> =</span> np.unravel_index(np.argmax(</span>self</span>.loc.bel),</span> self</span>.loc.bel.shape)</span></span>
    current_pose</span> =</span> self</span>.loc.mapper.from_map(</span>*</span>cell)</span></span>
</span>
    # 2. Turn-go-turn to next waypoint</span></span>
    rot1, trans</span> =</span> self</span>._plan_segment(current_pose,</span> self</span>.target_waypoint)</span></span>
    await</span> self</span>.robot.turn_to_heading(current_pose[</span>2</span>]</span> +</span> rot1)</span></span>
    await</span> self</span>.robot.drive_distance(trans)</span></span>
</span>
    # 3. Re-localize: 360° scan + Bayes update</span></span>
    await</span> self</span>.loc.get_observation_data() </span></span>
    self</span>.loc.update_step()</span></span></code></pre></iframe>
Collaboration</h2>
Thanks to Dyllan Hofflich for letting me run my PD code on Ananya Jajodia's car and working together with Dyllan Hofflich and Tina Cheng on the LQR derivation and tuning sessions. Thanks to Claude for helping debugging my inverted pendulum code and tuning process. Thanks to Professor Helbling and the entire teaching team of Fast Robots for a great semester. This is one of the best classes I have taken in college.</strong></p>

Parameter</th>	Value</th>	Why</th></tr></thead>
$K_p$</td>	15.0</td>	5° error → 75 PWM, above motor deadband</td></tr>
$K_d$</td>	1.0</td>	Rate damping to avoid oscillation</td></tr>
max pwm</td>	255</td>	Full authority for large disturbances</td></tr>
target pitch</td>	+90°</td>	Wheelie orientation in my IMU mounting</td></tr> </tbody></table> The reference's $K_p = 4$, $K_d = 0.2$ were sub-deadband: 5° → 20 PWM didn't move the wheels at all, then larger errors slammed past — a limit-cycle recipe. Tripling $K_p$ moved every meaningful correction above the motor's static-friction threshold.</p> Control law in firmware</h3> if</span> (stunt_state </span>==</span> IPEND_HOLD) {</span></span> float</span> pitch_rate_dps </span>= +</span>latest_gx;</span></span> float</span> deviation </span>=</span> latest_pitch_comp </span>-</span> ipend_cfg.target_pitch_deg;</span></span> float</span> u </span>=</span> ipend_cfg.Kp</span> </span> deviation</span></span> +</span> ipend_cfg.Kd</span> </span> pitch_rate_dps;</span></span> int</span> pwm </span>=</span> (</span>int</span>)</span>constrain</span>(u,</span> -</span>ipend_cfg.max_pwm,</span></span> +</span>ipend_cfg.max_pwm);</span></span> setLeftMotor</span>(pwm);</span></span> setRightMotor</span>(pwm);</span></span> }</span></span></code></pre> Both wheels get the same signed PWM — no differential needed.</p> IMU State Estimation</h2> I tried Aravind's Kalman observer first, but the estimate drifted unpredictably during fast maneuvers — translational acceleration from the cart kept contaminating the accelerometer pitch, the filter couldn't distinguish it from a true tilt, and the controller would saturate on phantom angles. After a couple of sessions tuning $\Sigma_u$ and $\Sigma_z$ to no avail, I went back to the complementary filter I already used in earlier labs:</p> pitch_lpf_state </span>=</span> ALPHA_LPF </span></span> pitch_acc </span>+</span> (</span>1</span> -</span> ALPHA_LPF)</span> </span> pitch_lpf_state;</span></span> pitch_comp_state </span>=</span> (</span>1</span> -</span> ALPHA_COMP)</span> </span> (pitch_comp_state </span>+</span> pitch_rate </span></span> dt)</span></span> +</span> ALPHA_COMP </span></span> pitch_lpf_state;</span></span></code></pre> The intuition is that the gyro is accurate on short timescales but drifts when integrated; the accelerometer is noisy on short timescales but absolute on long ones. With ALPHA_LPF = 0.10</code> and ALPHA_COMP = 0.05</code>, the filter trusts the gyro between frames and gently pulls toward the accel pitch over hundreds of milliseconds. At 50 Hz this is essentially as good as Kalman, with zero hyperparameters to retune per stunt.</p> Axis-swap calibration</h3> My IMU was mounted rotated 90° about the car z-axis, so car pitch showed up on IMU-y instead of IMU-x. I verified this by walking the car through five orientations and noting which accel channel saturated to ±1 g in each. Fixed by swapping which axes feed pitch and roll:</p> latest_pitch_acc </span>=</span> atan2</span>(latest_ay, latest_az)</span> </span> 180.0</span>f /</span> M_PI;</span></span> latest_roll_acc </span>=</span> atan2</span>(latest_ax, latest_az)</span> </span> 180.0</span>f /</span> M_PI;</span></span> float</span> pitch_rate </span>= +</span>latest_gx;</span></span></code></pre>Switching Cars + Tuning</h2> After days of fighting motor deadband and surface friction on my own car, I switch to path planning on the last day to have a complete deliverable. Coming back to the pendulum with Dyllan and Tina, we ran my PD code on Dyllan's car and it balanced for a couple of seconds, my controller was actually decent for Ananya's car. We then committed to Dyllan's full LQR formulation and tuned it together; the results below come from his car. Ultimately, it came down to whose code seemed to have a better balance results because what it is left was just tuning, and it seems like his code just provided a better starting point</p> Wheelie Launch State Machine - Attempt</h2> The launch sequence: drive forward to build linear momentum, brake hard to plant the front wheels, then reverse the motors. The wheels yank the contact point backward while the car's inertia keeps it moving forward, and the mismatch generates a forward-pitching torque about the front axle that lifts the rear into a wheelie. Once $\|\theta\| > 30°$, the FSM hands off to the balance controller. The FSM has one interesting state (BALANCE</code>); everything else is event-driven timing, with timeouts dropping back to IDLE</code> if the launch fails.</p> struct</span> WheelieConfig</span> {</span></span> int</span> forward_pwm </span>=</span> 250</span>;</span></span> int</span> forward_ms </span>=</span> 250</span>;</span></span> int</span> brake_ms </span>=</span> 100</span>;</span></span> int</span> reverse_pwm </span>=</span> 250</span>;</span></span> int</span> reverse_ms </span>=</span> 270</span>;</span></span> int</span> wait_max_ms </span>=</span> 600</span>;</span></span> float</span> balance_trigger_deg </span>=</span> 30.0</span>f</span>;</span></span> float</span> target_pitch_deg </span>= +</span>90.0</span>f</span>;</span></span> float</span> Kp </span>=</span> 15.0</span>f</span>;</span></span> float</span> Kd </span>=</span> 1.0</span>f</span>;</span></span> int</span> max_balance_pwm </span>=</span> 255</span>;</span></span> };</span></span></code></pre>Results</h2> My best controller</h3> Here's what my best inverted pendulum on Ananya's car. This is purely the code I developed on my own.</p> </iframe> First attempt</h3> We found that the performance of the controller with the initial gain matrix was pretty bad, with the robot oscillating a lot and not being able to balance for more than a second if at all.</p> </iframe> After tuning</h3> Instead of trying to tune the Q and R matrices to get a better gain matrix, we decided to just manually tune the gain matrix by hand.</p> </iframe> PID solution</h3> After struggling to get the LQR controller to work well, we attempted to implement a PID controller on a linearized system. It is a simple PID controller using the angle error from the DMP readings, we thought we had more experience tuning it from previous labs, but it just performed worse.</p> </iframe> Launch attempts</h3> Two attempts at the full launch-to-balance logic. The launch FSM reaches the trigger threshold, but the dynamic was super noisy, and our balance controller cannot handle it very well.</p> </iframe> </iframe> Surface comparison: wood vs. carpet</h3> Surface friction matters more than I expected. On wood the wheels slip during accelerations, so the controller cannot change fast enough, and the car tends to be less stable. On carpet the wheels bite and the controller's output actually moves the cart, which is what makes balance sustainable.</p> Best result on wood:</strong></p> </iframe> Best results on carpet:</strong></p> </iframe> </iframe> Final results — with weight on top</h3> The breakthrough was taping weights to the top of the chassis(with some further tuning of course). The higher $I_{b,\text{com}}$ lengthens the fall-time constant, which gives the controller more headroom to react to each disturbance. The pole has a much better stability. See the final clips at the bottom of Dyllan's Lab 12 report</a> for the best runs of the tuned LQR with weight added.</p> Bonus Videos & Bloopers</h2> Some of the more failures and side experiments from the tuning sessions.</p> </iframe> </iframe> </iframe> </iframe> </iframe> </iframe> </iframe> Tangent: Path Planning</h2> Overview of path planning. I worked on this for about six hours before joining Dyllan and Tina on the Inverted Pendulum. The task is to navigate 9 waypoints across the mapped arena, from $(-4, -3)$ to $(0, 0)$ in grid cells. I went with turn-go-turn between adjacent waypoints (no global planning — the waypoints are hand-designed and have no walls between consecutive points) and a Bayes-filter update at every waypoint, reusing the Lab 11 pattern: uniform-prior reset before each 360° scan, no prediction step (the provided $O(N^6)$ implementation is too slow for online use). Onboard PID handles both the in-place turn and the ToF-based straight leg; offboard Python plans the segments and await</code>s DONE</code> notifications from the firmware so the Bayes-filter compute doesn't compete with the 50 Hz control loop. A single waypoint takes 8–12 seconds end-to-end, dominated by the 18 turn-and-settle cycles of the localization scan. My best run hits the first 4–5 waypoints before cumulative heading drift (±5° per turn) points the car at a wall.</p> async def</span> step_once</span>(self):</span></span> # 1. Current pose = argmax of latest belief</span></span> cell</span> =</span> np.unravel_index(np.argmax(</span>self</span>.loc.bel),</span> self</span>.loc.bel.shape)</span></span> current_pose</span> =</span> self</span>.loc.mapper.from_map(</span></span>cell)</span></span> </span> # 2. Turn-go-turn to next waypoint</span></span> rot1, trans</span> =</span> self</span>._plan_segment(current_pose,</span> self</span>.target_waypoint)</span></span> await</span> self</span>.robot.turn_to_heading(current_pose[</span>2</span>]</span> +</span> rot1)</span></span> await</span> self</span>.robot.drive_distance(trans)</span></span> </span> # 3. Re-localize: 360° scan + Bayes update</span></span> await</span> self</span>.loc.get_observation_data() </span></span> self</span>.loc.update_step()</span></span></code></pre></iframe> Collaboration</h2> Thanks to Dyllan Hofflich for letting me run my PD code on Ananya Jajodia's car and working together with Dyllan Hofflich and Tina Cheng on the LQR derivation and tuning sessions. Thanks to Claude for helping debugging my inverted pendulum code and tuning process. Thanks to Professor Helbling and the entire teaching team of Fast Robots for a great semester. This is one of the best classes I have taken in college.</strong></p>

Home - Nonlinear Dynamic

Lab 12: Inverted Pendulum

Controller Design</h2>

Results</h2>

My best controller</h3> Here's what my best inverted pendulum on Ananya's car. This is purely the code I developed on my own.</p> </iframe>

First attempt</h3> We found that the performance of the controller with the initial gain matrix was pretty bad, with the robot oscillating a lot and not being able to balance for more than a second if at all.</p> </iframe>

After tuning</h3> Instead of trying to tune the Q and R matrices to get a better gain matrix, we decided to just manually tune the gain matrix by hand.</p> </iframe>

Launch attempts</h3> Two attempts at the full launch-to-balance logic. The launch FSM reaches the trigger threshold, but the dynamic was super noisy, and our balance controller cannot handle it very well.</p> </iframe> </iframe>

My best controller</h3>
Here's what my best inverted pendulum on Ananya's car. This is purely the code I developed on my own.</p> </iframe>

First attempt</h3>
We found that the performance of the controller with the initial gain matrix was pretty bad, with the robot oscillating a lot and not being able to balance for more than a second if at all.</p> </iframe>

After tuning</h3>
Instead of trying to tune the Q and R matrices to get a better gain matrix, we decided to just manually tune the gain matrix by hand.</p> </iframe>

Launch attempts</h3>
Two attempts at the full launch-to-balance logic. The launch FSM reaches the trigger threshold, but the dynamic was super noisy, and our balance controller cannot handle it very well.</p> </iframe> </iframe>