Balance is
a moving target.

01 / Purpose

What we set out to do.

Build a two-wheeled robot that can estimate its own tilt and correct it through motor control. Our course objective was to balance for one minute. Reaching that objective meant working across sensing, software, assembly, and power delivery.

View image

02 / Approach

How it came together.

An Arduino Nano 33 BLE Sense reads its LSM9DS1 inertial measurement unit. A complementary filter combines the accelerometer's estimate of gravity with short-term angular changes measured by the gyroscope. The resulting tilt estimate feeds the motor controller.

The submitted implementation uses MicroPython, a proportional controller, a deadband, output saturation, and a minimum PWM level to help overcome motor friction. It drives two DC motors through an L298N driver. This was a proportional-control prototype; it was not a fully tuned PID implementation.

The report describes a complementary-filter weight of 0.7, a 300-sample gyro calibration, and a control loop targeting approximately 100 Hz. These are implementation settings documented by the team, not independently measured timing guarantees.

03 / Contribution

The work, and the team.

I worked on this project in a four-person team with Mohammed Muqeet, Obaid Alaleeli, and Ibrahim Alhammadi. The work combined hardware assembly, sensor processing, motor control, and practical testing. The available report does not establish a reliable individual division of every task, so the implementation and results are credited to the team.

04 / Demonstration

What the visuals show.

The recorded prototype test below shows the physical build in use. It is a short demonstration, not evidence of a full 30-second balancing run. The Blender introduction explains sensing, hardware and correction using an illustrative model; its movement is not measured.

05 / Results

What we can say.

The submitted team report records best balancing runs of approximately 30 seconds on a hard, flat surface. The one-minute objective was not consistently achieved. This is a reported result from the coursework, not a new test reproduced for this portfolio.

06 / Limitations

Where the limits are.

The robot remained sensitive to controller tuning, battery condition, and the mechanics of the chassis. The report describes shakiness, a defective screw terminal, and power interruptions. Those issues made stable, repeatable behavior difficult to achieve.

The recorded best run should not be read as a guarantee across surfaces, battery levels, or repeated trials. A stronger evaluation would log tilt and motor commands, use a consistent starting condition, and repeat trials under controlled conditions.

07 / Lessons learned

What I’m taking forward.

This project made the relationship between software and hardware tangible. Filtering a signal is only useful when calibration, power, wiring, and the motor response are also dependable. The next useful step would be to improve those foundations, then tune and evaluate the controller with repeatable measurements.