Home

Lab 7: Kalman Filter

Shao Stassen — Mon, 23 Mar 2026 00:00:00 +0000

Drag and Mass Estimations</h2>

Approximating the robot as a first-order system using Newton's second law, factoring in linear drag $d$ and motor input $u$:

$$F = m\ddot{x} = -d\dot{x} + u$$

The dynamics in continuous state-space form ($\dot{x} = Ax + Bu$) with state vector $x = \begin{bmatrix} x \\ \dot{x} \end{bmatrix}$ are:

$$\begin{bmatrix} \dot{x} \\ \ddot{x} \end{bmatrix} = \begin{bmatrix} 0 & 1 \\ 0 & -\frac{d}{m} \end{bmatrix} \begin{bmatrix} x \\ \dot{x} \end{bmatrix} + \begin{bmatrix} 0 \\ \frac{1}{m} \end{bmatrix} u$$

I recorded three open-loop step responses at 150 PWM to extract parameters $d$ and $m$. Averaging these trajectories mitigated non-Gaussian Time-of-Flight (ToF) noise. Fitting an exponential decay to this consensus trajectory yielded a 70% rise time ($t_{0.7} = 1.05$ s) and steady-state velocity ($V_{ss} = 2.45$ m/s).

Assuming a normalized unit step input ($u = 1$), the parameters are calculated as:

$$d = \frac{u_{ss}}{\dot{x}_{ss}} = \frac{1}{2.45} = 0.408$$

$$m = \frac{-d \cdot t_{0.7}}{\ln(0.3)} = \frac{-0.408 \cdot 1.05}{-1.204} = 0.356$$

Plugging these into our continuous $A$ and $B$ matrices yields:

$$A = \begin{bmatrix} 0 & 1 \\ 0 & -1.146 \end{bmatrix}, \quad B = \begin{bmatrix} 0 \\ 2.809 \end{bmatrix}$$

Measuring only distance, our observation matrix $C$ isolates the first state:

$$C = \begin{bmatrix} 1 & 0 \end{bmatrix}$$

Average distance vs time for open loop step response</figcaption> </div>

Velocity and 70% rise time fit for open loop step response</figcaption> </div>

PWM graphs for open loop step response</figcaption> </div> </figure>

Here is a video of one of the trajectories while I was collecting data for a step response: </iframe>

Data Collection Video</figcaption>

Velocity and 70% rise time fit for a better open loop step response</figcaption> </figure>

Note: Subsequent trials with a closer braking distance yielded a slightly higher steady-state velocity, but my filter performed well with the initial dataset, so I proceeded with the originally calculated A and B matrices.

Kalman Python Simulation</h2>
System Timing and Discretization</h3>
The continuous model must be discretized using the fast onboard prediction loop (50 Hz, $\Delta t = 0.0209$ s) rather than the slower ToF sensor rate (~10 Hz, $\Delta t = 0.0985$ s) to prevent artificially accelerating the physics.
Discretizing via the first-order Taylor expansion ($A_d = I + A\Delta t$ and $B_d = B\Delta t$):
$$A_d = \begin{bmatrix} 1 & 0 \\ 0 & 1 \end{bmatrix} + \begin{bmatrix} 0 & 1 \\ 0 & -1.146 \end{bmatrix}(0.0209) = \begin{bmatrix} 1 & 0.0209 \\ 0 & 0.976 \end{bmatrix}$$
$$B_d = \begin{bmatrix} 0 \\ 2.809 \end{bmatrix}(0.0209) = \begin{bmatrix} 0 \\ 0.0587 \end{bmatrix}$$
import numpy as np # Discretized Matrices Ad = np.array([[1.0, 0.0209], [0.0, 0.976]]) Bd = np.array([[0.0], [0.0587]]) C = np.array([[1, 0]]) # Noise Covariances sig_u = np.array([[10.0**2, 0], [0, 10.0**2]]) sig_z = np.array([[20.0**2]]) # Kalman Filter Simulation Function def kalman_filter(mu, sigma, u, y_meas, has_new_data): # Predict Step mu_p = Ad.dot(mu) + Bd.dot(u) sigma_p = Ad.dot(sigma).dot(Ad.T) + sig_u if has_new_data: # Update Step y_m = y_meas - C.dot(mu_p) S = C.dot(sigma_p).dot(C.T) + sig_z K = sigma_p.dot(C.T).dot(np.linalg.inv(S)) mu = mu_p + K.dot(y_m) sigma = (np.eye(2) - K.dot(C)).dot(sigma_p) else: mu = mu_p sigma = sigma_p return mu, sigma</code></pre>Simulation Debugging</h3> Simulation Attempt 1: Unit Mismatch resulting in apparent zero velocity.</figcaption> </figure> 1. Unit Mismatch: The matrices initially predicted velocity in m/s, while raw data was plotted in mm/s, causing the accurate -3.1 m/s prediction to appear as a flat line on a -3000 mm/s scale. Recalculating matrices in millimeters fixed this. Simulation Attempt 2: Discretization timing mismatch causing extreme acceleration.</figcaption> </figure> 2. Discretization Mismatch: The simulated velocity reached steady-state too quickly (0.25s vs 1.06s) because $A_d$ and $B_d$ were mistakenly discretized using the 0.1s ToF rate instead of the simulation grid's interval. Using the correct $\Delta t = 0.0209$ s resolved the 5x artificial acceleration. Sensor Noise Characterization and Final Tuning</h3> Stationary tests revealed distance-dependent noise: $\sigma_{start} \approx 19.2$ mm (at 3800 mm) and $\sigma_{target} \approx 1.2$ mm (at 430 mm). Stationary Noise at Start (~3860mm): $sigma = 19.244$ mm</figcaption> </div> Stationary Noise near Target (~430mm): $sigma = 1.223$ mm</figcaption> </div> </figure> To prevent violent derivative kick at high speeds, I tuned the measurement covariance ($\Sigma_z$) for the worst-case scenario. $$ \Sigma_u = \begin{bmatrix} 100.0 & 0 \\ 0 & 100.0 \end{bmatrix}, \quad \Sigma_z = \begin{bmatrix} 400.0 \end{bmatrix} $$ In the Kalman Gain equation, setting $\Sigma_z = 400.0 \gg \Sigma_u = 100.0$ drastically shrinks the gain $K$. Consequently, the update equation ($\mu = \mu_p + K(y - C\mu_p)$) minimizes the impact of noisy sensor residuals. The system heavily trusts the physical prediction ($\mu_p$), allowing the velocity estimate to slice cleanly through the initial noise cloud. Simulation Attempt 3: Fully tuned Kalman Filter accurately tracking distance and filtering velocity.</figcaption> </figure> Onboard Robot Kalman Integration</h2> The BasicLinearAlgebra</code> library was used to port the matrices directly to the Artemis board. The control loop was decoupled from the sensor, executing the prediction step on a strict 50 Hz timer and updating only when the has_new_data</code> flag triggered. #include <BasicLinearAlgebra.h> using namespace BLA; BLA::Matrix<2,2> Ad = {1.0, 0.0209, 0.0, 0.976}; BLA::Matrix<2,1> Bd = {0.0, 0.0587}; BLA::Matrix<1,2> C = {1.0, 0.0}; BLA::Matrix<2,2> sig_u = {100.0, 0.0, 0.0, 100.0}; BLA::Matrix<1,1> sig_z = {400.0}; BLA::Matrix<2,1> mu = {0.0, 0.0}; BLA::Matrix<2,2> sigma = {10.0, 0.0, 0.0, 10.0}; void update_kalman(bool has_new_data, float measured_distance, float current_pwm) { BLA::Matrix<2,1> u = {current_pwm / 150.0f}; // Scale input to unit step BLA::Matrix<2,1> mu_p = Ad * mu + Bd * u; BLA::Matrix<2,2> sigma_p = Ad * sigma * ~Ad + sig_u; if (has_new_data) { BLA::Matrix<1,1> y = {measured_distance}; BLA::Matrix<1,1> S = C * sigma_p * ~C + sig_z; BLA::Matrix<1,1> S_inv = S; Invert(S_inv); BLA::Matrix<2,1> K = sigma_p * ~C * S_inv; mu = mu_p + K * (y - C * mu_p); sigma = (Eye<2>() - K * C) * sigma_p; } else { mu = mu_p; sigma = sigma_p; } }</code></pre>void executeControl() { uint32_t now = micros(); if (now - last_fast_loop_time >= 20000) { // 50Hz Fast Loop last_fast_loop_time = now; update_kalman(new_tof_data, dist_k, current_applied_pwm); new_tof_data = false; float kf_distance = mu(0,0); float raw_control_effort = computePID(linear_pid_setpoint, kf_distance); int actual_pwm = applyMotorSpeed(raw_control_effort); current_applied_pwm = actual_pwm; } }</code></pre>PID Tuning and Derivative Kick</h3> Phase 1: Extreme oscillation caused by Lab 5 derivative gains applied to the fast loop.</figcaption> </figure> Phase 1: Timing Mismatch: Applying Lab 5 PD gains ($K_p = 0.025$, $K_d = 20000$) to the 50 Hz loop caused violent oscillations. Because the new $\Delta t$ (0.020s) was five times smaller than the old ToF interval (0.098s), the discrete derivative ($K_d \frac{de}{dt}$) effectively multiplied the derivative kick by 5. Phase 2: Proportional-only control resulting in a slow approach and failure to stop.</figcaption> </figure> Phase 2: Coasting Baseline: Disabling the derivative term ($K_d = 0$) and using $K_p = 0.015$ eliminated oscillations, but without a derivative "brake," the robot coasted through the 304 mm target and crashed. Phase 3: Final tuned response utilizing the Kalman Filter for smooth, aggressive braking.</figcaption> </figure> Phase 3: Kalman Velocity Control: To safely restore braking power, I substituted the Kalman Filter's smoothed velocity state ($\mu_1$) for the noisy discrete derivative calculation: $$u(t) = K_p(x_{target} - \mu_0) - K_d(\mu_1)$$ This eliminated derivative chatter entirely. Approaching the 300 mm mark, $\mu_1$ applies a clean electronic braking force for a perfectly controlled stop. </iframe> Linear PID Test with Tuned Kalman Filter</figcaption> Final Remark</h3> While implementation was challenging, the resulting performance was highly satisfying. I achieved rapid initial acceleration (starting at max 255 PWM and decreasing to 100 PWM within the first second), covering significant distance quickly before the filter seamlessly executed the braking maneuver. Collaboration</h2> I referred to Jack Long and Aidan McNay's pages for graphing techniques and Kalman Filter C++ architectures. I collaborated with Ananya Jajodia on collecting step response data, and utilized ChatGPT to assist with data visualization and report formatting.

Lab 6: Orientation Control Shao Stassen — Tue, 17 Mar 2026 00:00:00 +0000 Objective</h2> The purpose of this lab is to implement a robust PID controller to manage the orientation (yaw) of the robot. This involves utilizing the IMU to perform in-place rotation using differential drive, while mitigating real-world sensor issues like gyroscope drift and derivative kick. Prelab: Bluetooth Architecture and Dynamic Setpoints</h2> To allow rapid tuning and mid-run setpoint changes, the Bluetooth handling was designed to be completely non-blocking. This is exactly how I transferred data in Lab 5 using commands. Instead of trapping the robot in a while</code> loop during a turn, the main loop()</code> continuously cycles through telemetry, sensor reading, and motor updating. This architecture allowed me to implement a dedicated UPDATE_YAW_SETPOINT</code> BLE command. case UPDATE_YAW_SETPOINT: { float new_yaw; success = robot_cmd.get_next_value(new_yaw); if (!success) return; rotational_setpoint = new_yaw; // ... [telemetry logging] break; }</code></pre> This satisfies the requirement to change the setpoint dynamically without halting the system. By passing new floats over Bluetooth, I can command the robot to snap to 90 degrees, and before it even finishes the turn, update the setpoint to -45 degrees seamlessly. PID Input Signal and Gyroscope Bias</h2> Initially, standard digital integration of the raw gyroscope data (gyrZ()</code>) was tested to estimate orientation. However, a stationary test revealed significant hardware bias and a ton of sensor noise (setting up for the Kalman filter), drifting at approximately -0.24 degrees per second. Yaw value of a stationary IMU sitting flat on the table</figcaption> </figure> Drift in yaw value of a stationary IMU over time</figcaption> </figure> Yaw value of the IMU performing a 360-degree turn</figcaption> </figure> As you can see from the figures above, the IMU works fairly well measuring yaw when rotating slowly, but this is not the case if the car is spinning at full speed, which incurs a lot of drift. This called the DMP to the rescue. The Digital Motion Processor (DMP) Solution</h3> To eliminate this bias, I bypassed manual integration and enabled the ICM-20948's onboard Digital Motion Processor (DMP). By configuring the DMP to output the 6-axis Game Rotation Vector (Quat6) at maximum speed (55Hz), the hardware's sensor fusion algorithm automatically corrects for drift in the background. // Keep reading until the FIFO queue is completely empty while (myICM.status == ICM_20948_Stat_FIFOMoreDataAvail) { myICM.readDMPdataFromFIFO(&data); } // ... [Quaternion to Euler conversion] ... yaw_g_state = raw_yaw - yaw_offset; // Zero out relative to start heading</code></pre> To prevent the DMP's internal FIFO queue from overflowing and crashing the sensor, a while</code> loop was used to completely drain the queue, ensuring the PID loop always acts on the freshest, completely drift-free quaternion data. Proportional Only Tune</h2> Initially, I started Kp at 0.9. Because the orientation ranges from -180 to 180 degrees, I mapped this against the PWM range using the deadband limit of 90 to 255 (a range of 165) that I learned from Lab 4. I then tuned the P value by increasing it slowly. Here is the result of this P-only controller targeting 90 degrees. </iframe> Initial P controller</figcaption> The Derivative Term and Anti-Kick</h2> It does not make sense to take the derivative of a signal that is the integral of another signal. Taking the mathematical derivative of the error (error - prev_error) / dt</code> just undoes the integration while amplifying digital noise. Furthermore, if the setpoint is suddenly changed (e.g., commanding a turn from 0° to 90° mid-run), the error instantly spikes. Taking the derivative of this sudden step-change results in a near-infinite spike in the D-term, causing the motors to jolt violently. Because the derivative of a constant setpoint is zero, the derivative of the error is mathematically equal to the negative of the actual rate of change. I bypassed the standard math and fed the raw gyroscope rate (-myICM.gyrZ()</code>) directly into the D-term. // ANTI-DERIVATIVE KICK: Use raw gyro rate instead of (error - prev_error)/dt float derivative = -gyro_rate; float D = Kd * derivative;</code></pre></iframe> With a setpoint of 90 degrees, the car reacts to constant external turning</figcaption> Yaw vs. time at 90 degrees with external disturbance</figcaption> </figure> Orientation Control and Tuning</h2> Control relies on differential drive, passing control_effort</code> to the left motor and -control_effort</code> to the right motor using the calibrated motor functions from Lab 5. During initial testing, I accidentally created a positive feedback loop because turning the robot physically right yielded a negative IMU angle, causing the error to grow rather than shrink. Flipping the motor command signs instantly fixed this. Here is an example of the error, where before the derivative term could brake the bot, its momentum carried it past the setpoint, resulting in constant spinning. </iframe> Positive feedback resulting in endless spinning </figcaption> During tuning, the integral term (Ki) was kept at 0 to avoid integrator wind-up at first, as steady-state error is minimal for free-spinning wheels on a smooth floor. I did implement wind-up protection (constrain(integral_sum, -50.0, 50.0);</code>), and later, when I noticed persistent small errors between my PD controller and the setpoints, I added the integral term. I increased the proportional gain (Kp) until the robot snapped to the target quickly, then applied the derivative gain (Kd) to dampen the resulting oscillations. Final Kp: 10.0</code></li> Final Kd: 0.5</code></li> Final Ki: 0.5</code></li> </ul> System Response and Results</h3> Below are the results of the tuned PID controller handling consecutive setpoints (0 -> 90 -> -90 -> 45 degrees) where I updated the yaw setpoint every 5 seconds. I tested this on two different surfaces: hard floor vs. carpet. </iframe> Floor setting</figcaption> Yaw vs. time with setpoint updates on floor</figcaption> </figure> </iframe> Carpet setting</figcaption> Yaw vs. time with setpoint updates on carpet</figcaption> </figure> Discussion</h2> When I was tuning the integral terms of the PID controller on the carpet, I observed the situation below: </iframe> High Pitch Sound on Carpet with No Motion</figcaption> After investigation, I realized this meant the battery was dying and simply needed to be charged. According to the ICM-20948 datasheet, the gyroscope has a programmable full-scale range (±250, ±500, ±1000, or ±2000 dps). During a rapid pivot, my robot easily spins faster than 250 dps. If left on the default ±250 dps setting, a fast turn would saturate the sensor, capping the output and causing my derivative "brake" to underestimate the speed. Using the ±2000 dps range provides ample headroom to capture the maximum rotational velocity. Because I bypassed standard error derivation and used the raw gyrZ() reading for Kd, any high-frequency mechanical vibration or electrical noise gets directly multiplied by Kd, causing motor jitter. I relied on the ICM-20948's built-in Digital Low-Pass Filter (DLPF) to clean up the raw data before feeding it into the PID math. Collaboration</h2> I referenced Lucca Correia's site for debugging and testing help. ChatGPT was used to help with some website formatting. Lab 5: Linear PID Control and Linear Interpolation Shao Stassen — Sun, 15 Mar 2026 00:00:00 +0000 Objective</h2> The goal is to implement a robust linear PID controller to drive the robot quickly toward a wall, stopping exactly 304mm (1 foot) away. Linear extrapolation is used to decouple the high-frequency PID control loop from the slower Time-of-Flight (ToF) sensor data rate. Prelab: Bluetooth Architecture and Debugging</h2> To prevent Serial.print</code> or Bluetooth delays from slowing down the PID loop, debugging data is stored locally in arrays during the run. The test sequence is controlled via Python over BLE. START_LINEAR_PID_DATA</code> triggers the control loop with the 304mm setpoint. SET_PID</code> allows real-time tuning of Kp, Ki, and Kd without recompiling. Once finished, STOP_LINEAR_PID_DATA</code> halts the motors and transmits the data to Python for visualization. This is almost exactly like how I have been transfer data in previous lab using commands. Here is an example of ToF data being sent over the network for debugging.</figcaption> </figure> Position Control Implementation</h2> ToF Sensor Configuration and Testing Challenges</h3> Initial testing was frustrating. I used the Long distanceMode</code> to potentially start up to 4 meters away, but the ToF sensor continuously failed to read past 1.8 meters on the ground. After hours of debugging and swapping between two cars, I found the culprits: both cars' ToF sensors pointed slightly downward, and the carpet strongly scattered the IR waves. Moving my tests to the hallway instantly fixed the reliability issues. While this provided clean data from 3 meters out, it reduced the sampling rate to roughly 20Hz. Motor Deadband and Scaling Calibration</h3> To allow micro-adjustments near the target, driveCalibrated()</code> handles the motor deadband. void driveCalibrated(float left_speed, float right_speed) { if(!motors_enabled) return; // Constrain before scaling to prevent full-throttle drift left_speed = constrain(left_speed, -255.0, 255.0); right_speed = constrain(right_speed, -255.0, 255.0); left_speed *= left_motor_scaling; right_speed *= right_motor_scaling; if (fabs(left_speed) > 0.1) { int pwm_l = map(fabs(left_speed), 0, 255, min_pwm_left, 255); pwm_l = constrain(pwm_l, min_pwm_left, 255); // ... (Directional logic and right motor logic follows)</code></pre> The PID output maps an effort of "1" to the minimum PWM needed to overcome static friction (~40 PWM). The raw input is constrained before scaling, ensuring straight driving even at maximum PID output. Proportional (P) Control Tuning</h3> Starting 3000mm away with a 304mm setpoint creates a massive initial error (~2696mm). Kp of 1 would dangerously saturate the motors. A viable gain range to keep commands within 0-255 bounds is between Kp = 0.005 (conservative) and 0.009 (aggressive). My initial tests were from 1800mm due to the early sensor issues. </iframe> 1800mm P Test</figcaption> P-only PID control, ToF Distance vs. Time </figcaption> </figure> While P-control was fairly accurate, higher speeds caused overshoot. Adding a Derivative (Kd) term acted as a brake, allowing a higher P-term. </iframe> 1800mm PD Test</figcaption> PD control, ToF Distance vs. Time </figcaption> </figure> My final tuned gains were Kp = 0.0025, Kd = 20000.0, and Ki = 0. I omitted the I-term since there was no observable steady-state error. Linear Extrapolation</h2> The Sampling Rate Problem</h3> The ToF sensor runs at 18-20Hz, but the main PID loop executes hundreds of times per second. Without extrapolation, using stale distance data for 50ms causes jerky movements and discrete derivative steps. Implementation</h3> To decouple these rates, readToF()</code> calculates the PID effort every loop cycle. If no new data is ready, it estimates the current distance using velocity from the last two readings: $$d_{est} = d_{last} + (v \cdot \Delta t)$$ float estimated_distance = last_known_dist; if (!new_data_available && prev_known_time > 0) { float dt_history = (last_known_time - prev_known_time) / 1000000.0f; if (dt_history > 0.0f) { float velocity = (last_known_dist - prev_known_dist) / dt_history; float time_since_last = (current_time - last_known_time) / 1000000.0f; estimated_distance = last_known_dist + (velocity * time_since_last); } } // Execute PID immediately using the estimated distance if (run_linear_pid) { float control_effort = computePID(linear_pid_setpoint, estimated_distance); driveCalibrated(control_effort, control_effort); }</code></pre>Extrapolated Results</h3> With extrapolation, the PID loop runs continuously at over 150Hz. The robot smoothly ramps down its motor speed between sensor flashes, allowing higher top speeds safely. The plots show true sensor readings at ~20Hz alongside high-frequency motor command adjustments. I recorded three trials of this extrapolated controller. </iframe> Trial 1 Video</figcaption> </div> Trial 1: ToF Distance vs. Time</figcaption> </figure> </div> </div> </iframe> Trial 2 Video</figcaption> </div> Trial 2: ToF Distance vs. Time</figcaption> </figure> </div> </div> </iframe> Trial 3 Video</figcaption> </div> Trial 3: ToF Distance vs. Time</figcaption> </figure> </div> </div> Motor effort is the negative of PWM, due to some sign in calculation that's hard to fix. The max speed I acheieve with my linear PID while successful is approximately 1 m/s, this could be find via slope from above graphs. Finally, I shoved the car while the linear PID was active to test how well it adapted to changing states and external disturbances. </iframe> Disturbance Test Video</figcaption> Discussion and Additional Implementations</h2> To ensure the robot drove straight even when the PID demanded maximum effort, I implemented pre-constraining on the PID output before applying the differential motor scaling factors. I also kept the Bluetooth read_data()</code> and write_data()</code> handlers entirely non-blocking so the main control loop could maintain its high-frequency execution. Collaboration</h2> I collaborated on this project with Ananya Jajodia on troubleshooting my car. I also referenced Aiden Derocher's site for debugging and testing help. ChatGPT was used to help with some website formatting. Lab 4: Motor Drivers and Open Loop Control Shao Stassen — Mon, 02 Mar 2026 00:00:00 +0000 Prelab</h2> Wire Schematic</h3> To control the motors, I utilized the PWM-capable pins on the Artemis Nano. I assigned pins 15 and 14 for the Left Motor (forward and backward, respectively) and 2 and 3 for the Right Motor. These pins were chosen to keep the wiring organized and relatively localized on the board, leaving the other side available for future sensor expansion. To ensure the motors receive enough current without overheating the motor drivers, the inputs and outputs of each dual motor driver were parallel-coupled. This effectively combines the two channels of a single IC, doubling the average current capacity sent to each DC motor. System Circuit Schematic</figcaption> </figure> Lab Tasks</h2> Soldering the Circuit</h3> Below is an image of the finished, soldered physical circuit. (Note: The circuit had not been mounted into the chassis before my initial PWM tests; I just forgot to photograph it prior to this step!) Finished System Circuit</figcaption> </figure> Power Supply and Oscilloscope Hookup</h3> Before integrating the drivers into the car, I tested the PWM outputs using an oscilloscope and an external power supply. The power supply was set to 3.7V with a conservative current limit to simulate the 850mAh Li-Ion battery, which prevents any real damage in the event of a short circuit or a bad soldering job. To verify the PWM generation, I used the following basic code to send a duty cycle of approximately 23% (60/255) to pin 15, representing the forward direction: #define MOTOR_INL1 15 #define MOTOR_INL2 14 void setup() { pinMode(MOTOR_INL1, OUTPUT); pinMode(MOTOR_INL2, OUTPUT); analogWrite(MOTOR_INL1, 0); analogWrite(MOTOR_INL2, 0); } void loop() { analogWrite(MOTOR_INL1, 60); analogWrite(MOTOR_INL2, 0); } </code></pre></iframe> Left Motor Driver PWM Test</figcaption> Oscilloscope capturing the PWM signal</figcaption> </figure> </iframe> Regulated Left Motor Driver PWM Test</figcaption> Oscilloscope capturing the PWM signal</figcaption> </figure> </iframe> Regulated Right Motor Driver PWM Test</figcaption> Motor Testing</h3> After validating the signal, I dismantled the Force1 RC car. I decided not to remove the stock PCB, thinking the flat surface would be useful for mounting my components (although I ultimately didn't take much advantage of it for this lab). I then cut the motor leads and wired up the left motor driver first, keeping the chassis elevated so the wheels could spin freely. During this phase, I ran into a frustrating bug while testing the second motor driver. I wrote the exact same PWM code to verify the motor functioned correctly, but it refused to spin. After extensive troubleshooting, I finally connected the VIN</code> and GND</code> leads of both motor drivers together into the power supply, and it worked perfectly—even though I was only actively controlling one driver. This is a classic grounding issue. In complex or high-power robotics—like the 3lb autonomous combat robots built for competition—ensuring a shared, common ground between your logic controller (the Artemis) and your motor drivers is critical. Without a shared ground reference, the PWM signal from the Artemis essentially "floats." The motor driver cannot accurately determine what constitutes a logic HIGH (3.3V) or a logic LOW (0V), meaning the motors won't activate. </iframe> Right Motor Driver Test (Elevated)</figcaption> </iframe> Right Motor Driver Test (Elevated)</figcaption> </iframe> Both Motors Running on Power Supply</figcaption> Once both sides were verified, I transitioned power from the bench supply to the 3.7V 850mAh battery to ensure the system could run untethered. </iframe> Both Motors Running on Battery Power</figcaption> Complete Hardware Integration on Car</h3> All components were packed securely into the chassis. The motor drivers were zip-tied toward the center to keep wire runs to the motors short. The Artemis and IMU were mounted near the middle to keep the center of gravity balanced, and the two ToF sensors were placed to ensure clear lines of sight. I made sure no components stuck out past the wheels so the car could safely roll or flip without damaging the electronics. Top-down view of the fully integrated chassis</figcaption> </figure> Right View </div> Left View </div> </div> Side profiles of the fully integrated chassis</figcaption> Motor Functions</h3> To make testing easier for the remainder of this lab and future assignments, I integrated helper functions for motor control (moveForward</code>, moveBackward</code>, turnLeft</code>, turnRight</code>, stopMotors</code>, and speed adjustments) into my main Artemis code. I also mapped these functions to commands sent over Bluetooth. For the sake of brevity, I haven't included the Bluetooth parsing code here, as it was documented in the previous three labs. void moveForward() { analogWrite(MOTOR_INL1, motorSpeed); analogWrite(MOTOR_INL2, 0); analogWrite(MOTOR_INR1, motorSpeed); analogWrite(MOTOR_INR2, 0); } void moveBackward() { analogWrite(MOTOR_INL1, 0); analogWrite(MOTOR_INL2, motorSpeed); analogWrite(MOTOR_INR1, 0); analogWrite(MOTOR_INR2, motorSpeed); } void turnLeft() { analogWrite(MOTOR_INL1, 0); analogWrite(MOTOR_INL2, motorSpeed); analogWrite(MOTOR_INR1, motorSpeed); analogWrite(MOTOR_INR2, 0); } void turnRight() { analogWrite(MOTOR_INL1, motorSpeed); analogWrite(MOTOR_INL2, 0); analogWrite(MOTOR_INR1, 0); analogWrite(MOTOR_INR2, motorSpeed); } void stopMotors() { analogWrite(MOTOR_INL1, 0); analogWrite(MOTOR_INL2, 0); analogWrite(MOTOR_INR1, 0); analogWrite(MOTOR_INR2, 0); } </code></pre>Lower PWM Limit</h3> To find the minimum PWM value required to overcome the gearbox's static friction (the "deadband"), I placed the car on the floor and slowly ramped up the motorSpeed</code> variable. On a full charge, the minimum PWM to move both forward and backward was about 40-41. In an earlier test (shown in the first video below), I decremented the PWM from high to low and found a slightly higher minimum limit of 44. This discrepancy is likely due to a lower battery charge at the time. Because PWM is a percentage of the total voltage, a dying battery provides a lower average voltage to the motors, meaning a higher PWM value is required to achieve the same physical torque. Executing an on-axis turn required a significantly higher minimum PWM of 145. This is due to the physics of skid steering: to turn in place, the wheels are forced to drag laterally across the ground, generating vastly more static friction than moving in a straight line. It is worth noting that I conducted this turning test on a different surface with a higher coefficient of friction, so the minimum PWM for turning on the standard lab floor may be lower. for i in range(15): ble.send_command(CMD.SET_SPEED, str(25+i)) ble.send_command(CMD.FORWARD, "") time.sleep(1) # ble.send_command(CMD.BACKWARD, "") # time.sleep(1) # ble.send_command(CMD.LEFT, "") # time.sleep(2) # ble.send_command(CMD.RIGHT, "") # time.sleep(2) print(f"Speed set to: {25+i}") ble.send_command(CMD.STOP, "") </code></pre> Here are the videos documenting the lower limit tests: </iframe> Decremental Limit Test with Forward and Backward</figcaption> </div> Your browser does not support the video tag. </video> </div> Your browser does not support the video tag. </video> </div> Your browser does not support the video tag. </video> </div> </div> Calibration</h3> Due to mechanical variances, providing the exact same PWM value to both motors caused the car to drift noticeably. To achieve a straight 2-meter run, I implemented a multiplicative calibration factor. I started both leftCalibration</code> and rightCalibration</code> at 1.0</code>. After observing the car veering left (which indicates the right wheels were spinning faster and driving the chassis to the left), I iteratively increased the left calibration float down to 1.2</code>. Because calibration multipliers can sometimes push a base speed over the maximum 8-bit PWM limit, I also implemented the constrain()</code> function as a safety measure to prevent integer overflow. int motorSpeed = 100; float leftCalibration = 1.2; float rightCalibration = 1.0; void moveForward() { int actualLeftSpeed = motorSpeed * leftCalibration; int actualRightSpeed = motorSpeed * rightCalibration; actualLeftSpeed = constrain(actualLeftSpeed, 0, 255); actualRightSpeed = constrain(actualRightSpeed, 0, 255); analogWrite(MOTOR_INL1, actualLeftSpeed); analogWrite(MOTOR_INL2, 0); analogWrite(MOTOR_INR1, actualRightSpeed); analogWrite(MOTOR_INR2, 0); } void turnLeft() { int actualLeftSpeed = motorSpeed * leftCalibration; int actualRightSpeed = motorSpeed * rightCalibration; actualLeftSpeed = constrain(actualLeftSpeed, 0, 255); actualRightSpeed = constrain(actualRightSpeed, 0, 255); analogWrite(MOTOR_INL1, 0); analogWrite(MOTOR_INL2, actualLeftSpeed); analogWrite(MOTOR_INR1, actualRightSpeed); analogWrite(MOTOR_INR2, 0); } </code></pre> With the calibration applied, the car successfully followed a straight line found on the floor in Upson Hall using forward commands sent from the Python backend. You can see a massive difference in stability before and after calibration. Example of the Starting Point</figcaption> </figure> Your browser does not support the video tag. </video> Your browser does not support the video tag. </video> Open Loop Testing</h2> Your browser does not support the video tag. </video> Discussion</h2> Although this lab report is shorter compared to previous ones, the lab itself has definitely taken the most amount of time. From soldering the full circuit (which took way longer than anticipated), to testing the PWM signals and overcoming the grounding roadblocks, to iteratively calibrating the robot to drive in a straight line, it was a heavy workload. Despite the calibration, the open-loop drive is still not perfect. It is prone to slipping and drifting over long distances, which really highlights the limitations of relying purely on dead reckoning. I am looking forward to implementing PID control using sensor feedback for much better reliability in the future. Collaboration</h2> I collaborated extensively on this project with Ananya Jajodia and Dyllan Hofflich. I referenced Aiden Derocher's site for wiring help and PWM testing. ChatGPT was used for some website formatting. Lab 4: Motor Drivers and Open Loop Control Shao Stassen — Mon, 02 Mar 2026 00:00:00 +0000 Prelab</h2> Wire Schematic</h3> To control the motors, I utilized the PWM-capable pins on the Artemis Nano. I refer to Lucca Correial's website for identify which pins can do PWM. I assigned pins 15 and 14 for the Left Motor (forward and backward, respectively) and 2 and 3 for the Right Motor. These pins were chosen to keep the wiring organized and relatively localized on the board. From lecture and further research, parallel-couple the inputs and outputs of each dual motor driver ensure the motors receive enough current without overheating the motor drivers. This effectively combines the two channels of a single IC, doubling the average current capacity sent to each DC motor. Here is my full circuit schematic include work from lab 1-4. System Circuit Schematic</figcaption> </figure> Battery Discussion</h3> We use two separate batteries—one for the Artemis and one for the motor drivers—to isolate our logic circuitry from electrical noise and voltage drops. DC motors are significant inductive loads; when they rapidly change speed or reverse direction, they can pull large spikes of current and generate back-EMF. If the Artemis were powered by the same supply, these fluctuations could cause the microcontroller to brown-out, reset, or register false readings on the sensors. Lab Tasks</h2> Soldering the Circuit</h3> Below is an image of the finished, soldered physical circuit. (Note: The circuit had not been mounted into the chassis before my initial PWM tests; I just forgot to photograph it prior to this step!) Finished System Circuit</figcaption> </figure> Power Supply and Oscilloscope Hookup</h3> Before integrating the drivers into the car, I tested the PWM outputs using an oscilloscope and an external power supply. The power supply was set to 3.7V with a conservative current limit to simulate the 850mAh Li-Ion battery, which prevents any real damage in the event of a short circuit or a bad soldering job. Here is the image of the setup: Oscilloscope Hookup</figcaption> </figure> Power Supply Hookup</figcaption> </figure> To verify the PWM generation, I used the following basic code to send a duty cycle of approximately 23% (60/255) to pin 15, representing the forward direction: #define MOTOR_INL1 15 #define MOTOR_INL2 14 void setup() { pinMode(MOTOR_INL1, OUTPUT); pinMode(MOTOR_INL2, OUTPUT); analogWrite(MOTOR_INL1, 0); analogWrite(MOTOR_INL2, 0); } void loop() { analogWrite(MOTOR_INL1, 60); analogWrite(MOTOR_INL2, 0); } </code></pre> Here is video showing my probe setup, as well as the results: </iframe> Left Motor Driver PWM Test</figcaption> The analogWrite(MOTOR_INL1,60) line indicated a 23.5% (60/255) duty cycle to pin 15. Oscilloscope graph: Oscilloscope capturing the PWM signal</figcaption> </figure> Now I used a for loop to incrementally increase the PWM from 0 to 255 on the left motor, and this is a video showing this: </iframe> Regulated Left Motor Driver PWM Test</figcaption> Here is the example graph for the PWM being regulated: Oscilloscope capturing the PWM signal</figcaption> </figure> Switch to the right motor, and do the same regulating test: </iframe> Regulated Right Motor Driver PWM Test</figcaption> Motor Testing</h3> After validating the signal, I dismantled the RC car. I decided not to remove the stock PCB, thinking the flat surface would be useful for mounting my components (although I ultimately didn't take much advantage of it for this lab). I then cut the motor leads and wired up the left motor driver first, keeping the chassis elevated so the wheels could spin freely. During this phase, I ran into a frustrating bug while testing the second motor driver. I wrote the exact same PWM code to verify the motor functioned correctly, I can also the motor try to spin from the hum sound, but it refused to spin. After extensive troubleshooting, I finally connected the VIN</code> and GND</code> leads of both motor drivers together into the power supply, and it worked perfectly—even though I was only actively controlling one driver. Here is some of the results of the PWM test on actual motors: </iframe> Right Motor Driver Test (Elevated)</figcaption> </iframe> Right Motor Driver Test (Elevated)</figcaption> </iframe> Both Motors Running on Power Supply</figcaption> Once both sides were verified, I transitioned power from the bench supply to the 3.7V 850mAh battery to ensure the system could run untethered. </iframe> Both Motors Running on Battery Power</figcaption> Complete Hardware Integration on Car</h3> All components were packed securely into the chassis. The IMU were zip-tied in the front of the bot on the flat surface of the battery case. The motor drivers sits a bit back from there. I put both batteries in the battery case. The Artemis is mounted in the back of the car, and the two ToF sensors were placed in the front and the left side to ensure clear lines of sight. In this way, I try to keep all the high voltage component away from the sensors, try to keep the EMI as low as possible. I made sure no components stuck out past the wheels so the car could safely roll or flip without damaging the electronics. (Failed driving tests, ie. running into the wall, have shown, this is indeed reliable.) Top-down view of the fully integrated chassis</figcaption> </figure> Right View </div> Left View </div> </div> Side profiles of the fully integrated chassis</figcaption> Motor Functions</h3> To make testing easier for the remainder of this lab and future assignments, I integrated helper functions for motor control (moveForward</code>, moveBackward</code>, turnLeft</code>, turnRight</code>, stopMotors</code>, and speed adjustments) into my main Artemis code. I also mapped these functions to commands sent over Bluetooth. For the sake of brevity, I haven't included the Bluetooth parsing code here, as it was documented in the previous three labs. void moveForward() { analogWrite(MOTOR_INL1, motorSpeed); analogWrite(MOTOR_INL2, 0); analogWrite(MOTOR_INR1, motorSpeed); analogWrite(MOTOR_INR2, 0); } void moveBackward() { analogWrite(MOTOR_INL1, 0); analogWrite(MOTOR_INL2, motorSpeed); analogWrite(MOTOR_INR1, 0); analogWrite(MOTOR_INR2, motorSpeed); } void turnLeft() { analogWrite(MOTOR_INL1, 0); analogWrite(MOTOR_INL2, motorSpeed); analogWrite(MOTOR_INR1, motorSpeed); analogWrite(MOTOR_INR2, 0); } void turnRight() { analogWrite(MOTOR_INL1, motorSpeed); analogWrite(MOTOR_INL2, 0); analogWrite(MOTOR_INR1, 0); analogWrite(MOTOR_INR2, motorSpeed); } void stopMotors() { analogWrite(MOTOR_INL1, 0); analogWrite(MOTOR_INL2, 0); analogWrite(MOTOR_INR1, 0); analogWrite(MOTOR_INR2, 0); } </code></pre>Lower PWM Limit</h3> To find the minimum PWM value required to overcome the gearbox's static friction (the "deadband"), I placed the car on the floor and slowly ramped up the motorSpeed</code> variable. On a full charge, the minimum PWM to move both forward and backward was about 40-41. In an earlier test (shown in the first video below), I decremented the PWM from high to low and found a slightly higher minimum limit of 44. This discrepancy is likely due to a lower battery charge at the time. Because PWM is a percentage of the total voltage, a dying battery provides a lower average voltage to the motors, meaning a higher PWM value is required to achieve the same physical torque. Executing an on-axis turn required a significantly higher minimum PWM of 135. This is due to the physics of skid steering: to turn in place, the wheels are forced to drag laterally across the ground, generating vastly more static friction than moving in a straight line. It is worth noting that I conducted this turning test on a different surface with a higher coefficient of friction, so the minimum PWM for turning on the standard lab floor may be lower. for i in range(15): ble.send_command(CMD.SET_SPEED, str(25+i)) ble.send_command(CMD.FORWARD, "") time.sleep(1) # ble.send_command(CMD.BACKWARD, "") # time.sleep(1) # ble.send_command(CMD.LEFT, "") # time.sleep(2) # ble.send_command(CMD.RIGHT, "") # time.sleep(2) print(f"Speed set to: {25+i}") ble.send_command(CMD.STOP, "") </code></pre> Here are the videos documenting the lower limit tests: </iframe> Decremental Limit Test with Forward and Backward</figcaption> </div> </iframe> Turning Limit Test</figcaption> </div> </iframe> Forward Limit Test</figcaption> </div> </iframe> Backward Limit Test</figcaption> </div> </div> Calibration</h3> Due to mechanical variances, providing the exact same PWM value to both motors caused the car to drift noticeably. To achieve a straight 2-meter run, I implemented a multiplicative calibration factor. I started both leftCalibration</code> and rightCalibration</code> at 1.0</code>. After observing the car veering left (which indicates the right wheels were spinning faster and driving the chassis to the left), I iteratively increased the left calibration float down to 1.2</code>. Because calibration multipliers can sometimes push a base speed over the maximum 8-bit PWM limit, I also implemented the constrain()</code> function as a safety measure to prevent integer overflow. int motorSpeed = 100; float leftCalibration = 1.2; float rightCalibration = 1.0; void moveForward() { int actualLeftSpeed = motorSpeed * leftCalibration; int actualRightSpeed = motorSpeed * rightCalibration; actualLeftSpeed = constrain(actualLeftSpeed, 0, 255); actualRightSpeed = constrain(actualRightSpeed, 0, 255); analogWrite(MOTOR_INL1, actualLeftSpeed); analogWrite(MOTOR_INL2, 0); analogWrite(MOTOR_INR1, actualRightSpeed); analogWrite(MOTOR_INR2, 0); } void turnLeft() { int actualLeftSpeed = motorSpeed * leftCalibration; int actualRightSpeed = motorSpeed * rightCalibration; actualLeftSpeed = constrain(actualLeftSpeed, 0, 255); actualRightSpeed = constrain(actualRightSpeed, 0, 255); analogWrite(MOTOR_INL1, 0); analogWrite(MOTOR_INL2, actualLeftSpeed); analogWrite(MOTOR_INR1, actualRightSpeed); analogWrite(MOTOR_INR2, 0); } </code></pre> With the calibration applied, the car successfully followed a straight line found on the floor in Upson Hall using forward commands sent from the Python backend. You can see a massive difference in stability before and after calibration. Example of the Starting Point</figcaption> </figure> </iframe> Straight Test Before Calibration</figcaption> </iframe> Straight Test After Calibration</figcaption> Open Loop Testing</h2> Finally, I try to move the car in a race track manner, by have it move forward, turn left, move around the curve, turn left, move forward again, then turn. In general this drive is not great, but it achieve its goal. </iframe> Open Loop Test</figcaption> Discussion</h2> Although this lab report is shorter compared to previous ones, the lab itself has definitely taken the most amount of time. From soldering the full circuit (which took way longer than anticipated), to testing the PWM signals and overcoming the grounding roadblocks, to iteratively calibrating the robot to drive in a straight line, it was a heavy workload. Despite the calibration, the open-loop drive is still not perfect. It is prone to slipping and drifting over long distances, which really highlights the limitations of relying purely on dead reckoning. I am looking forward to implementing PID control using sensor feedback for much better reliability in the future. Collaboration</h2> I collaborated extensively on this project with Ananya Jajodia and Dyllan Hofflich. I referenced Aiden Derocher's site for wiring help and PWM testing. ChatGPT was used for some website formatting. Lab 3: Time of Flight Sensors Shao Stassen — Mon, 23 Feb 2026 00:00:00 +0000 Overview</h2> In Lab 3, the objective was to test out the functionalities and capabilities of two VL53L1X Time-of-Flight (ToF) sensors while still having the IMU. The faster and more reliably the robot can sample these distances, the faster it can safely drive. This lab involved permanently wiring the sensors, powering the Artemis from a battery, bypassing I2C address conflicts, and streaming accurate and reliable ToF data over Bluetooth alongside the IMU. Sensor Placement Strategy</h3> I plan to mount one ToF sensor on the front center of the car to detect obstacles directly in the driving path, and the other on the side of the car between the wheels. This configuration will allow the robot to avoid forward collisions while simultaneously maintaining a set distance from the sides for tasks, based on what I know from future labs. Blind spots: Because the sensors have a relatively narrow Field of View, the robot will likely miss obstacles that are lower than the sensor's mounting height, highly reflective/angled surfaces that bounce the IR light away, or thin obstacles that fall between the front and side sensor's cone of vision. These blind spots will need to be taken into great consideration in the future when I am doing localization. I2C Address Conflict</h3> Using the Example05_Wire_I2C.ino</code> sketch, I scanned the bus and successfully found the default ToF at address 0x29</code>, and the IMU at address 0x69</code> on port 0x10000E9C</code>. I determined those numbers specifically by doing isolation tests on the sensors. I2C Device Scanning with only the Time of Flight plugged in</figcaption> </figure> I2C Device Scanning with both the Time of Flight and IMU plugged in</figcaption> </figure> Both VL53L1X sensors share the same hardwired default I2C address (0x29</code>). This was a bit unexpected, because its datasheet said that the default address is 0x52</code>. After further investigation, I realized that the address is left-shifted by 1 bit, since the LSB is used for read/write. Since I2C requires unique addresses for each device on the bus, I cannot simply plug both into the Qwiic connector and work with both of them simultaneously. To solve this, I used the XSHUT</code> (shutdown) pin. By wiring the XSHUT</code> pin of ToF sensor 2 to an output pin on the Artemis (Pin A0), I can hold Sensor 2 in hardware shutdown during boot. I then initialize Sensor 1, use software to change its address to 0x30</code>, and finally pull XSHUT</code> high to wake up Sensor 2 at the default 0x29</code> address. The following is the code that implements what I described above. WIRE_PORT.begin(); WIRE_PORT.setClock(400000); Serial.println("Booting ToF Sensors..."); pinMode(SHUTDOWN_PIN, OUTPUT); digitalWrite(SHUTDOWN_PIN, LOW); delay(50); sensor1.begin(); sensor1.setI2CAddress(0x30); digitalWrite(SHUTDOWN_PIN, HIGH); delay(50); sensor2.begin(); sensor1.setDistanceModeShort(); sensor2.setDistanceModeLong(); </code></pre>Hardware Setup</h2> I prepared the Artemis by soldering the provided 650mAh RC car battery to a JST jumper cable. I was careful to cut and strip the wires one at a time to avoid shorting the battery. After soldering, I used heat shrink tubing to insulate the exposed wire. I verified the polarity (positive to positive) before plugging it into the Artemis. Soldered Battery</figcaption> </figure> I then successfully tested this by running my BLE Python script and sending some test messages back and forth without the USB-C cable connected. Python server on messaging tests on battery</figcaption> </figure> Artemis on messaging tests on battery</figcaption> </figure> </div> Finally, I cut one end off of 2 Qwiic cables and soldered one to each of the ToF sensors, noting the color coding (Blue = SDA, Yellow = SCL, Red = 3.3V, Black = GND). And I connected them to the Qwiic connector hub, as shown below in the circuit diagram. Circuit Diagram</figcaption> </figure> Sensor Modes, Dual Sensor Integration & Testing</h2> The VL53L1X technically supports three distance modes: Short: Max distance ~1.3m. Better ambient light immunity.</li> Medium: Max distance ~3m.</li> Long: Max distance ~4m. Default mode, but highly sensitive to ambient light and lower accuracy at close range.</li> </ul> The Medium Mode: I decided to ignore the medium mode for this lab, since it is supported only through the Pololu VL53L1X Library, which would require me to change a lot of the code for the ToF. If I find that I may need something in between short and long mode in the future, I will consider looking at this more carefully. Below is the initial test I did after hooking up both of the ToF sensors and having them both function simultaneously. Note this satisfies Task 8, so I jumped ahead. Refer to the code snippet in the I2C Address section for how I got both of them to work. </iframe> Two ToF test</figcaption> </iframe> Serial Monitor - Two ToF test</figcaption> ToF Sensor Speed and Non-Blocking Code</h2> In future labs, the robot cannot hang while waiting for a laser to bounce back. To ensure the code executes as fast as possible, I wrote a non-blocking loop that continuously printed the Artemis millis()</code> clock, and only printed ToF data when checkForDataReady()</code> was true. Loop Execution Speed: The millis()</code> timestamps incremented every 3 to 4 ms, indicating that the main loop executes at roughly 250 to 330 Hz.</li> Sampling Rate: Sensor 1 (~46.5 Hz): Looking at some sample data, averaging those gives roughly 21.5 ms per sample, which means Sensor 1 is operating at an average rate of 46.5 Hz. Sensor 2 (~11 Hz): Sensor 2 only gets data once while Sensor 1 gets data 4 times; it is visually obvious it is running much slower.</li> </ul> Speed test 1</figcaption> </figure> Speed test 2</figcaption> </figure> </div> Sensor Discrepancies: During testing, Sensor 1 sampled significantly faster than Sensor 2. This is because I set Sensor 1 to short mode and Sensor 2 to long mode. Because long mode can reach further, its waves also take longer to travel back.</li> </ul> // print code void loop() { Serial.print("Time (ms): "); Serial.println(millis()); if (sensor1.checkForDataReady()) { int dist1 = sensor1.getDistance(); sensor1.clearInterrupt(); Serial.print(">>>> SENSOR 1 READY: "); Serial.print(dist1); Serial.println(" mm"); } if (sensor2.checkForDataReady()) { int dist2 = sensor2.getDistance(); sensor2.clearInterrupt(); Serial.print(">>>> SENSOR 2 READY: "); Serial.print(dist2); Serial.println(" mm"); } } </code></pre>Data Collection over Bluetooth</h2> First, I wanted to compare the performance difference between the long mode and short mode for the ToF by starting from a white wall, and then slowly dragging my ToF sensors back from the wall for 30+ seconds. Here are the results I got: (Note: I collected 2 trials of each for consistency comparison). TOF short mode test 1</figcaption> </figure> TOF short mode test 2 </figcaption> </figure> TOF long mode test 1</figcaption> </figure> TOF long mode test 2</figcaption> </figure> Metric Evaluation:</h3> Range: Short Mode: The graphs show a perfectly linear tracking line that abruptly drops to 0 mm just past 2100 mm (~2.1 meters). This defines the absolute maximum physical range in short mode before the sensor's confidence threshold fails. This is higher than expected from the short mode.</li> Long Mode: The sensors track linearly up to approximately 4800 mm (~4.8 meters). Beyond this point, the signal breaks down into massive noise spikes (erratically jumping between 0 and 5000 mm). And the noise becomes really bad starting at ~4.2 meters. But this is again higher than expected for long mode.</li> </ul> Accuracy: Across all four graphs, Sensor 1 (blue) and Sensor 2 (red) overlap almost perfectly during the valid range window. The steady, linear slope as the distance increases demonstrates that the sensors scale proportionally and accurately with real-world distance, with minimal deviation between the two physical units. Repeatability: The sensor performance is incredibly consistent. Comparing Short 1 to Short 2, both trials hit their failure point at the exact same ~2100 mm mark. Similarly, Long 1 and Long 2 both experience total signal breakdown at the identical ~4800 mm threshold. The noise profiles and slopes are virtually indistinguishable between trials. Ranging Time: There is a direct trade-off between range and speed. Short mode allows for a much tighter timing budget (20ms), yielding a fast ranging time of approximately ~45 Hz. To achieve the 4+ meter range in Long mode, the sensors require a larger timing budget (50ms) to leave the optical shutter open longer, reducing the ranging speed to roughly ~20 Hz. From this experiment, I decided to test the accuracy further by measuring a set distance. I made a setup with a measuring tape, using the provided white board as an object to detect and my box to hold the sensor in one position, with the tape measure recording the right distance, imaged below: Setup</figcaption> </figure> ToF Accuracy Analysis (Static Distance Tests)</h3> I collected static data at four precise distances: 100mm, 200mm, 500mm, and 1000mm. I used a reflective whiteboard as the target. I performed these tests in both Long Mode and Short Mode to compare their performance. 100mm and 200mm Testing 100 mm - Short Mode</figcaption> </figure> 100 mm - Long Mode</figcaption> </figure> 200 mm - Short Mode</figcaption> </figure> 200 mm - Long Mode</figcaption> </figure> </div> 500mm and 1000mm Testing 500 mm - Short Mode</figcaption> </figure> 500 mm - Long Mode</figcaption> </figure> 1000 mm - Short Mode</figcaption> </figure> 1000 mm - Long Mode</figcaption> </figure> </div> Analyzing these graphs reveals a disparity between Short and Long mode, which is heavily exacerbated by the reflective whiteboard target: Short Mode is Highly Accurate: Across all four distances (100mm, 200mm, 500mm, and 1000mm), Short mode performed really well. The data lines are flat, stable, and cluster very tightly around the true distance. For instance, at 1000mm, both sensors tracked cleanly between 980mm and 1000mm. At 500mm, they were nearly perfectly aligned with the 500mm mark. Long Mode: In stark contrast, Long mode failed at close ranges. At 100mm, the Long mode data is pretty noisy, oscillating randomly between 50mm and 200mm. Even at 1000mm, Long mode under-reads the actual distance by nearly 100mm and exhibits high-frequency jitter. Now, this is a bit unfair for long mode because it is designed to look for faint signals from up to 4 meters away, so it increases its sensitivity and leaves its optical "shutter" open longer. Pointing this highly sensitive mode at a glossy, highly reflective whiteboard at a close distance of 100mm effectively "blinds" the sensor. Sensor Offset: I also observed a slight, consistent offset between Sensor 1 and Sensor 2. Because the physical test setup was identical, this minor variance is likely due to the placement of my ToFs at slightly different angles, causing them to hit the whiteboard at very slightly different angles. Conclusion: These tests definitively prove that for a small room with a lot of reflection, Short Mode wins because of its accuracy and speed. Long mode's sensitivity to reflection makes it untrustworthy at sub-1-meter distances in this specific environment. However, if future labs require greater than 2 meter distance detection, I would need to use Long mode or implement Medium mode. IMU and ToF</h3> I created a new Bluetooth command (START_BOTH</code>) that simultaneously collects data from the ToF sensors and the IMU (using the Complementary Filter developed in Lab 2). case START_BOTH: { recordBoth = true; tof_sample_idx = 0; s1_read_done = false; s2_read_done = false; temp_dist1 = 0; temp_dist2 = 0; // Reset IMU timing so filters start fresh imu_samples = 0; t_start_us = micros(); t_last_us = t_start_us; imu_state_initialized = false; tx_estring_value.clear(); tx_estring_value.append("BOTH_RECORDING_STARTED"); tx_characteristic_string.writeValue(tx_estring_value.c_str()); break; } </code></pre>void loop() { BLEDevice central = BLE.central(); if (central) { while (central.connected()) { loop_count++; // Non-blocking IMU calculation runs if requested if ((recordIMU || recordBoth)) { if (myICM.dataReady()) { collectIMU(); } } // Non-blocking ToF sampling if ((recordToF || recordBoth) && tof_sample_idx < MAX_SAMPLES) { // Throttle I2C polling to every 5ms static uint32_t last_tof_check = 0; if (micros() - last_tof_check > 5000) { last_tof_check = micros(); if (!s1_read_done && sensor1.checkForDataReady()) { temp_dist1 = sensor1.getDistance(); sensor1.clearInterrupt(); s1_read_done = true; } if (!s2_read_done && sensor2.checkForDataReady()) { temp_dist2 = sensor2.getDistance(); sensor2.clearInterrupt(); s2_read_done = true; } // Once BOTH sensors are ready, record everything! if (s1_read_done && s2_read_done) { tof_time_buffer[tof_sample_idx] = micros(); tof1_buffer[tof_sample_idx] = temp_dist1; tof2_buffer[tof_sample_idx] = temp_dist2; // If doing combined recording, grab the most recent IMU state if (recordBoth) { pitchcomp_buffer[tof_sample_idx] = pitch_comp_state; rollcomp_buffer[tof_sample_idx] = roll_comp_state; } tof_sample_idx++; s1_read_done = false; s2_read_done = false; } } } write_data(); read_data(); } } } </code></pre> Because the IMU calculates data much faster than the ToF sensors, the IMU updates its angles in the background continuously. Whenever the ToF sensors finish a distance reading, the Artemis grabs the most recent IMU pitch and roll and saves all five variables into parallel arrays. Distance and IMU Complementary Pitch and Roll vs. Time for over 10 seconds</figcaption> </figure> As seen in the graph above, all three sensors (2 ToFs and 1 IMU) are successfully running in parallel without blocking each other. Collaboration</h2> I collaborated extensively on this project with Ananya Jajodia. I referenced Lucca Correia's site for the I2C address and ToF speed test, and Aidan Derocher's site for the wiring diagram and ToF testing. ChatGPT was used for plotting CSV data and sending ToF data over Bluetooth. Lab 2: IMU Shao Stassen — Tue, 10 Feb 2026 00:00:00 +0000 Overview</h2> In Lab 2, I integrated a 9DOF IMU with the SparkFun RedBoard Artemis Nano, computed orientation estimates from accelerometer and gyroscope data, analyzed accelerometer noise in the frequency domain, implemented a low-pass filter (LPF), and fused accelerometer + gyroscope estimates with a complementary filter. Finally, I powered the RC car from a battery and recorded driving “stunts” to establish a baseline for future autonomous behavior. IMU Setup</h2> Hardware connections</h3> I connected the SparkFun ICM-20948 IMU breakout to the Artemis using the QWIIC connectors (I2C). The image below shows this setup. I also added a visual indicator by blinking the Artemis LED 3 times on boot; there is an image for this as well. Artemis + IMU wiring via QWIIC</figcaption> </figure> Artemis with blue LED indicator</figcaption> </figure> Example code works</h3> I verified basic IMU functionality using the SparkFun library example: Library: SparkFun 9DoF IMU Breakout - ICM 20948 - Arduino Library</li> Example: Example1_Basics</code></li> </ul> I modified the code in the example slightly in order to get the serial prints and plotter to work nicely. However, this didn't impact the actual values, so there was minimal effect. I confirmed that acceleration (mg) and gyroscope (DPS) values updated as expected while rotating and translating the board. </iframe> Example Code IMU Test</figcaption> AD0_VAL (what it is + what it should be)</h3> AD0_VAL</code> represents the least significant address-selection bit for the IMU’s I2C address (effectively selecting between the two possible I2C addresses depending on the AD0/ADR pin state). In practice: If the IMU ADR/AD0 line is left at its default, AD0_VAL</code> should match that default.</li> If the ADR jumper is bridged/closed, AD0_VAL</code> must be changed accordingly.</li> </ul> In my setup, AD0_VAL = 1</code> because I am just using the default configuration. Initial sensor behavior (what changes and why)</h3> From the example output and the calculated roll, pitch, and yaw values for both the accelerometer and gyroscope (shown in later videos): Accelerometer: Changes with linear acceleration and also reflects gravity. When the board is still but tilted, the acceleration vector changes because gravity is distributed differently across axes. I also noticed that the accelerometer's data is very noisy. This is expected, since accelerometers are highly sensitive to small vibrations, mechanical disturbances, and electrical noise.</li> Gyroscope: Changes with angular velocity. When I rotate about an axis, I see a spike primarily on the corresponding gyro axis; when stationary, gyro values return to near zero. For the above example, you can see my gyroscope values stay mostly near zero because my motion is relatively slow, resulting in a small angular velocity being measured.</li> </ul> Another important thing is that the parameters change based on the axis being rotated about. For example, when you rotate about the x-axis, you see that the pitch changes the most compared to the other two axes. Accelerometer</h2> Pitch and roll from acceleration</h3> Using the equations from the lecture, I converted raw accelerometer readings into pitch and roll (degrees). I used atan2()</code> for robust quadrant handling. #include <math.h> pitch_a = atan2(accX, accZ) * 180.0 / M_PI; roll_a = atan2(accY, accZ) * 180.0 / M_PI; </code></pre> The video below showcases how I obtained 0, -90, and 90 degrees for the pitch and roll from the accelerometer. </iframe> Roll and Pitch IMU Test</figcaption> Specifically, the 5 images below are static images of me hitting those specific angles. As the images indicate, the accuracy of the accelerometer is pretty decent, as the values are close to their true values, but they are not super precise. I used a 2-point calibration to attempt to make it a bit better. Specifically for pitch, true 0 degrees is about 2 degrees, and true -90 degrees is about -88 degrees. This is easy to fix; you just need to add a 2-degree offset. The roll value is a bit more complicated because true 0 degrees is roughly -1.5, true -90 degrees is about -91, and true 90 degrees is about 92 degrees. Using the slope function, we get the following, where a</code> is the slope and b</code> is the offset: a = (y2 - y1) / (x2 - x1) = 180 / 183 = 0.9836065574 b = y2 - a*x2 = 90 - 0.9836065574*92 = -0.4918032787 </code></pre>Accuracy of the accelerometer</h3> 0 degree - both</figcaption> </figure> pitch 90 degree</figcaption> </figure> pitch -90 degree</figcaption> </figure> roll 90 degree</figcaption> </figure> roll -90 degree</figcaption> </figure> </div> pitch = pitch - 2; roll = 0.9836066 * roll - 0.4918033; </code></pre> 0 degree - pitch</figcaption> </figure> 0 degree - roll</figcaption> </figure> pitch 90 degree</figcaption> </figure> pitch -90 degree</figcaption> </figure> roll 90 degree</figcaption> </figure> roll -90 degree</figcaption> </figure> </div> The calibrated results end up looking pretty good for pitch and roll at the different critical values. Data from Accelerometer</h3> I made a new command in the Artemis code to collect the IMU sensor data with a certain number of samples (in this case, 2048 samples) and transmit them to the Python server. Once the data arrives as a string, I parse them into separate arrays by the type of data (i.e., pitch_a, roll_a, etc.). I then used them to plot graphs for analysis and results. case GET_IMU_READINGS: { float Micros = 0; float pitch = 0; float roll = 0; if (!success) { return; } // First, collect all data for (int i = 0; i < MAX_SAMPLES; i++) { while (!myICM.dataReady()) {} myICM.getAGMT(); Micros = micros(); pitch = atan2(myICM.accX(), myICM.accZ()) * 180 / M_PI; roll = atan2(myICM.accY(), myICM.accZ()) * 180 / M_PI; time_buffer[i] = Micros; roll_buffer[i] = roll; pitch_buffer[i] = pitch; } // Then, send the collected data for (int x = 0; x < MAX_SAMPLES; x++) { tx_estring_value.clear(); tx_estring_value.append(time_buffer[x]); tx_estring_value.append(":"); tx_estring_value.append(pitch_buffer[x]); tx_estring_value.append(":"); tx_estring_value.append(roll_buffer[x]); tx_characteristic_string.writeValue(tx_estring_value.c_str()); } Serial.print("Done"); break; } </code></pre> Then I used a similar notification handler as in Lab 1 for reading the data. def make_notification_handler(controller): def handler(sender: int, byte_array: bytearray): try: msg = controller.bytearray_to_string(byte_array) sep = msg.find(":") if sep != -1: times.append(msg[:sep]) sep2 = msg.find(":", sep+1) pitches.append(msg[sep+1:sep2]) rolls.append(msg[sep2+1:]) except Exception: msg = bytes(byte_array).decode(errors="ignore") # Strip common C-string padding / line endings msg = msg.strip("\x00\r\n ") return handler handler = make_notification_handler(ble) ble.stop_notify(ble.uuid['RX_STRING']) ble.start_notify(ble.uuid['RX_STRING'], handler) print("Listening for notifications") ble.send_command(CMD.GET_ACC_READINGS, "") </code></pre> Here is the example plotting code I used to generate the different graphs. import pandas as pd import matplotlib.pyplot as plt times = [int(t) for t in times] pitches = [float(p) for p in pitches] rolls = [float(r) for r in rolls] pitches = [p-2 for p in pitches] rolls = [(0.9836066 * r - 0.4918033) for r in rolls] t_s = (np.array(times) - times[0]) / 1000000.0 # ms -> s, relative to start plt.figure(figsize=(10,5)) plt.plot(t_s, pitches, label='Pitch', linewidth=1, color='blue') plt.xlabel('Time (s)') plt.ylabel('Angle (degrees)') plt.title('IMU: Pitch vs Time') plt.legend() plt.grid(True) plt.tight_layout() plt.show() plt.figure(figsize=(10,5)) plt.plot(t_s, rolls, label='Roll', linewidth=1, color='red') plt.xlabel('Time (s)') plt.ylabel('Angle (degrees)') plt.title('IMU: Roll vs Time') plt.legend() plt.grid(True) plt.tight_layout() plt.show() </code></pre> Raw pitch and roll vs. time with RC car in proximity</figcaption> </figure> The plots above show raw accelerometer-derived pitch and roll over about 6 seconds. Both signals stay near 0° but exhibit high-frequency oscillations—roughly ±1° for both pitch and roll, indicating sensor noise and vibration from the proximity of the RC car. This raw data is what drives the use of a low-pass filter to reduce noise, which I will analyze in the next section. FFT and Low-Pass Filter</h3> I performed an FFT analysis to characterize accelerometer noise and chose a cutoff frequency for the low-pass filter. Using the Frequency Spectrum to Choose a Cutoff Frequency</h2> To determine an appropriate cutoff frequency for the low-pass filter, I analyzed the accelerometer-derived pitch and roll signals in the frequency domain using the Fast Fourier Transform (FFT). Before computing the FFT, I subtracted the mean of each signal to remove the dominant DC component caused by gravity, allowing the vibration and noise content to be more clearly observed. The resulting frequency spectra show that the majority of the signal energy is concentrated at very low frequencies, corresponding to slow changes in orientation. Beyond this region, the spectrum becomes relatively flat and noisy, indicating high-frequency vibrations rather than meaningful motion. When the RC car was running nearby, noticeable energy appeared primarily below approximately 0 - 8 Hz, with no strong, structured peaks at higher frequencies. Based on this observation, I decided to pick an end value where most of that noise lies, resulting in a cutoff frequency near 8 Hz for the low-pass filter. This cutoff preserves the low-frequency components associated with real robot motion while attenuating higher-frequency noise. Choosing a cutoff that is too low would over-smooth the signal and suppress legitimate motion (such as a quick tilt or turn), while choosing a cutoff that is too high would allow excessive vibration noise to remain in the signal. Low-Pass Filter Design and Effect on the Data</h2> To implement the low-pass filter, I used a 4th-order Butterworth filter, which provides a smooth passband and strong attenuation beyond the cutoff frequency. The filter was designed using the inferred sampling frequency of the IMU data and applied using a zero-phase filtfilt</code> operation to avoid phase distortion. In the time domain, the effect of the low-pass filter is clearly visible. The raw pitch and roll signals exhibit rapid, high-frequency oscillations on the order of ±1°, even when the sensor remains near a constant orientation. After filtering, these oscillations are significantly reduced, while the overall trend of the signal is preserved. This confirms that the removed components primarily correspond to noise rather than meaningful motion. The FFT of the filtered signal further validates this choice: frequency components above the cutoff frequency are strongly attenuated, while low-frequency content remains largely unchanged. Together, the frequency-domain and time-domain results demonstrate that the selected cutoff frequency effectively balances noise reduction and signal fidelity. Relation to Filter Parameters in Code</h2> The cutoff frequency directly determines the filter coefficients used in the Butterworth design. As explained in lecture, the cutoff frequency $f_c$ is related to the time constant $RC$ by $$f_c = \frac{1}{2\pi RC}$$ and the smoothing factor $\alpha$ is related to the sampling period $T$ by $$\alpha = \frac{T}{T + RC}$$ To solve for this theoretical value, I used this code: t_array = np.array(times) / 1e6 fs = 1 / np.mean(np.diff(t_array)) T = 1 / fs fc = 5.0 RC = 1 / (2 * math.pi * fc) alpha = T / (T + RC) </code></pre> I got an alpha of 0.129 using the cutoff frequency of 8 Hz. In practice, rather than explicitly computing $\alpha$, I implemented the low-pass filter using a digital Butterworth filter, which internally accounts for the sampling frequency and cutoff frequency. This approach provides a more consistent frequency response and better attenuation characteristics than a simple first-order filter. Below are the frequency-domain plots and raw vs. LPF comparisons. FFT of accelerometer data — car in proximity</figcaption> </figure> Raw vs. low-pass filtered accelerometer data</figcaption> </figure> FFT: Raw vs. LPF</figcaption> </figure> Additional vibration and FFT analysis: To deliberately induce vibrational noise, I placed the IMU on the lab table and gently tapped the table with my hand. As you might notice, the peaks in the following graphs are vibration noise from those impacts—the accelerometer picks up the mechanical shock as high-frequency spikes in pitch and roll. These spikes are generated just by my finger taps. This setup helps characterize how impulsive disturbances affect the raw signal and how well the low-pass filter attenuates them. You can see that the raw signal contains a lot of vibration noise, but the low-pass filter is able to smooth them out. Vibration Pitch and Roll — table taps</figcaption> </figure> Vibration FFT raw vs. low-pass filtered — table-tap vibration noise</figcaption> </figure> Raw vs. low-pass filtered — table-tap vibration noise</figcaption> </figure> Gyroscope</h2> Pitch, roll, and yaw from gyroscope</h3> I integrated angular velocity (DPS) over time to obtain pitch, roll, and yaw angles from the gyroscope: delta = (micros() - curr_time) / 1000000.0; curr_time = micros(); pitch = pitch + myICM.gyrX() * delta; roll = roll + myICM.gyrY() * delta; yaw = yaw + myICM.gyrZ() * delta; </code></pre>Gyroscope vs. accelerometer</h3> The gyroscope and accelerometer use different axis conventions on the ICM-20948, as we learned in lecture. The gyro pitch/roll axes correspond to the accel roll/pitch axes (with a sign flip for pitch). So I had to correct this mapping in the code with the following edit: float pitch_rate = -myICM.gyrY(); float roll_rate = myICM.gyrX(); float yaw_rate = myICM.gyrZ(); pitch_g += pitch_rate * dt; roll_g += roll_rate * dt; yaw_g += yaw_rate * dt; </code></pre> Gyroscope vs Accelerometer in orientation</figcaption> </figure> For the most part, the gyroscope tracks quick rotations smoothly but drifts over time due to integration error. The accelerometer is more accurate at low frequencies but is noisy. A complementary filter combines both to get a stable and accurate orientation. Currently, I am at the highest sampling frequency with no delay. I tried putting sleep</code> in the sample data call, which would decrease the sampling frequency. In general, the estimated angles showed increased lag and reduced responsiveness to quick motions. This makes sense because at larger time steps, you miss rapid changes, causing high-frequency vibrations to appear as low-frequency drift. Complementary Filter</h2> I fused the low-pass filtered accelerometer angles with the integrated gyroscope angles using a complementary filter: roll_comp[i] = (roll_comp[i-1] + roll_G[i] * dt) * (1 - alpha) + rollLPF[i] * alpha; pitch_comp[i] = (pitch_comp[i-1] + pitch_G[i] * dt) * (1 - alpha) + pitchLPF[i] * alpha; </code></pre> Using an alpha of 0.05 for both the LPF and the complementary filter (which weights the gyroscope for short-term stability and the accelerometer for long-term accuracy), I got something like this: const float alphaLPF = 0.05f; const float alphaComp = 0.05f; </code></pre> Complementary filter: gyro vs. LPF accelerometer vs. fused</figcaption> </figure> However, you might notice that the graph of the complementary filter is smooth but not very accurate, or it doesn't respond well to changes compared to the LPF's graph. This means I needed to increase the contribution of the accelerometer's LPF to get a smooth and drift-corrected roll and pitch. const float alphaLPF = 0.10f; const float alphaComp = 0.05f; </code></pre> Best Complementary filter: gyro vs. LPF accelerometer vs. fused</figcaption> </figure> Now this looks better! Working range and accuracy</h3> Working range: The complementary filter performs well across the typical operating range of pitch and roll—roughly ±90°. Beyond that, for these positions, the accelerometer-based angles become ill-defined (e.g., when the board is nearly vertical, the atan2 formulation approaches singularities), and the gyroscope integration accumulates more drift. This was knowledge from the microcontroller class. Accuracy: With alphaComp = 0.05</code> and alphaLPF = 0.10</code>, the fused output tracks the LPF accelerometer really well while staying smoother than the raw accel. The filter accuracy is ultimately limited by the accelerometer (calibration, noise) at low frequencies and by the gyroscope (bias, integration error) at high frequencies. Based on my graph, however, it seems to have very good accuracy. Sampling Data</h2> Speed up</h3> I optimized the main loop to sample the IMU as fast as possible: Non-blocking data collection: Instead of blocking on myICM.dataReady()</code> inside the command handler, I check dataReady()</code> in the main loop and call collectIMU()</code> only when new data is available. Data is stored in arrays and sent over Bluetooth in a separate command.</li> Removed debug prints in the IMU read path to reduce overhead.</li> Start/stop flags so recording only runs when requested via Bluetooth commands.</li> </ol> The main loop runs much faster than the IMU produces data, so the IMU is the bottleneck. Comparing loop_count</code> (main loop count) to imu_samples</code> (samples collected) shows the loop cycles many times per IMU sample. void loop() { // Listen for connections BLEDevice central = BLE.central(); if (central) { // While central is connected while (central.connected()) { loop_count++; // Non-blocking IMU sampling if (recordIMU && sample_idx < MAX_SAMPLES) { if (myICM.dataReady()) { myICM.getAGMT(); // Timing uint32_t now_us = micros(); float dt = (now_us - t_last_us) / 1e6f; t_last_us = now_us; // Protect against weird dt (first sample / overflow / etc.) if (dt <= 0 || dt > 0.1f) dt = 0.0f; // Accel -> pitch/roll (deg) float pitch_a = atan2(myICM.accX(), myICM.accZ()) * 180.0f / M_PI; float roll_a = atan2(myICM.accY(), myICM.accZ()) * 180.0f / M_PI; // Gyro rates (deg/s) with your axis mapping: float pitch_rate = -myICM.gyrY(); float roll_rate = myICM.gyrX(); float yaw_rate = myICM.gyrZ(); // Initialize persistent states ONCE per recording if (!imu_state_initialized) { pitch_g_state = pitch_a; roll_g_state = roll_a; yaw_g_state = 0.0f; // pitch_lpf_state = pitch_a; // roll_lpf_state = roll_a; // pitch_comp_state = pitch_a; // roll_comp_state = roll_a; imu_state_initialized = true; } // Integrate gyro angles pitch_g_state += pitch_rate * dt; roll_g_state += roll_rate * dt; yaw_g_state += yaw_rate * dt; // // Low-pass accel angles // pitch_lpf_state = alphaLPF * pitch_a + (1.0f - alphaLPF) * pitch_lpf_state; // roll_lpf_state = alphaLPF * roll_a + (1.0f - alphaLPF) * roll_lpf_state; // // Complementary filter (gyro prediction + accel correction) // pitch_comp_state = (1.0f - alphaComp) * (pitch_comp_state + pitch_rate * dt) + alphaComp * pitch_lpf_state; // roll_comp_state = (1.0f - alphaComp) * (roll_comp_state + roll_rate * dt) + alphaComp * roll_lpf_state; // Store into arrays int i = sample_idx; time_buffer[i] = now_us; pitch_buffer[i] = pitch_a; // raw accel angle roll_buffer[i] = roll_a; pitchg_buffer[i] = pitch_g_state; // integrated gyro angle rollg_buffer[i] = roll_g_state; yawg_buffer[i] = yaw_g_state; // pitchLPF_buffer[i] = pitch_lpf_state; // filtered accel // rollLPF_buffer[i] = roll_lpf_state; // pitchcomp_buffer[i] = pitch_comp_state; // fused // rollcomp_buffer[i] = roll_comp_state; sample_idx++; imu_samples++; // Stats dt_last = dt; dt_avg = dt_avg + (dt - dt_avg) / imu_samples; } } // Send data write_data(); // Read data read_data(); } } } </code></pre> Notice I decided to only send time, raw pitch and roll from the accelerometer, and pitch, roll, and yaw from the gyroscope. This is because I could compute the low-pass filtered values and complementary values on the Python server. This design choice was made to allow me to push through more data as quickly as possible. Data storage</h3> I used separate float arrays for time (which is an int), raw accel roll/pitch, and gyro roll/pitch/yaw. With 4 bytes per float (6 values) + delimiting characters (5), that is 44 bytes per sample. In particular, compared to alternative options, representing a float or int as a string takes up more space if the number is more than 4 digits. This is true for all of our data; therefore, I believe I am using the most efficient way to store these values. Lab 2 global variables use 131,832 bytes. The Artemis has 384 kB RAM, leaving roughly 252 kB for dynamic allocation. At 44 bytes per sample, this allows storing about 5700 samples. At a ~330 Hz (see below for the calculation) sample rate, that corresponds to roughly 17 seconds of continuous IMU data. 5 seconds of IMU data</h3> I collected at least 5 seconds of IMU data and sent it over Bluetooth to verify the pipeline. This section demonstrates that I can send 5 seconds of IMU data, showing the stored IMU data array with timestamps and start/end flags. ble.send_command(CMD.START_IMU, "") # start flag time.sleep(5) ble.send_command(CMD.STOP_IMU, "") # end flag time.sleep(0.2) ble.send_command(CMD.SEND_IMU, "") # actual method for sending data over BLE </code></pre> Here is the beginning and end of the csv for the data I collected for about 5.1 seconds. Beginning of the IMU data collected for 5+ seconds</figcaption> </figure> End of the IMU data collected for 5+ seconds</figcaption> </figure> There is a total of 1663 samples collected in 5 seconds, which gives about 1663 / 5 = 332.6 Hz for data transfer. RC Stunts</h2> Below are videos of the RC car stunts powered by battery. </iframe> RC car stunt 1</figcaption> </iframe> RC car stunt 2</figcaption> From playing with the car, I noticed that the RC car is quick at reacting to any signal sent from the controller. I observed the car's turning, driving straight, and drifting. It has a great self-turning mechanism if you hold down the turning trigger. I also noticed that it seems to maintain a constant speed while turning, and how easily it can be flipped over. Bonus: I was able to get the RC car on its side and drive it with only 2 wheels on the ground. Not really useful, but I thought it was interesting. Collaboration</h3> I collaborated with: Ananya Jajodia. I referenced: Lucca Correia's site for FFT debugging and Sampling data section. ChatGPT was used for: code debugging + plot generation + website formatting. Lab 1: Artemis and Bluetooth Shao Stassen — Tue, 03 Feb 2026 00:00:00 +0000 Lab 1A</h2> During section 1A, I installed the Arduino IDE and the corresponding libraries and board manager following a given tutorial and hooked up a physical connection from my computer to communicate with the SparkFun RedBoard Artemis Nano. After selecting the correct Board (RedBoard Artemis Nano) and Port, I verified programming and serial communication by running the required example sketches: Basics_blink</li> Apollo3_serial</li> Apollo3_analogRead</li> PDM_microphoneOutput</li> </ul> Blink</h3> The Artemis board flashed its onboard LED as expected. </iframe> Blink test video</figcaption> Serial</h3> The Artemis received a string over USB serial and echoed it back as I typed into the Serial Monitor, confirming serial RX/TX. </iframe> Serial communication test</figcaption> AnalogRead with Temperature Sensor</h3> The onboard temperature sensor responded to heat (touch/breath), showing changing readings over time. In this case, I was blowing hot air to increase the temperature. </iframe> Temperature sensor test</figcaption> Microphone Output</h3> The PDM microphone output changed with voice/whistle input, confirming the microphone pipeline works. In this case, I was whistling in the background to increase the sound frequency. </iframe> Microphone output test</figcaption> Part A of this lab is mainly to set up and test if the microcontroller functions properly with the computer, which it does. Lab 1B</h2> Introduction</h3> With regards to the prelab and background reading, this is what I understand: Bluetooth Low Energy (BLE) enables a lightweight communication link between my computer and the Artemis board. At a high level: The Artemis acts as a BLE peripheral that advertises a service (UUID).</li> The computer acts as the BLE central, connects to the advertised service, and interacts with characteristics.</li> Characteristics support operations like Read, Write, and Notify. In this lab, I used Write to send commands to the Artemis and Notify to stream messages back to the laptop.</li> </ul> The code provided to me supports, including but not limited to, the following functionality: ble_arduino.ino: Arduino sketch running on the Artemis (defines service + RX/TX characteristics and command handling).</li> RobotCommand.h: parses incoming command strings of the form <cmd_type>:<value1>|<value2>|...</code></li> EString.h: safely constructs outgoing strings (including float formatting) without relying on printf float support.</li> demo.ipynb: Python/Jupyter notebook used to connect, send commands, and receive notifications.</li> </ul> Useful functions: ble.connect() / ble.disconnect()</code></li> ble.send_command(cmd_type, data)</code></li> ble.start_notify(uuid, handler)</code></li> ble.bytearray_to_string(byteArray)</code></li> </ul> Setup</h3> Installed virtual environment tooling: python3 -m pip install --user virtualenv</code></li> Created venv: python3 -m venv FastRobots_ble</code></li> Activated: source FastRobots_ble/bin/activate</code></li> Installed packages: pip install numpy pyyaml colorama nest_asyncio bleak jupyterlab</code></li> Started JupyterLab: jupyter lab</code></li> After running uuid4()</code>, I updated connections.yaml with my Artemis MAC address (from the Serial Monitor) and a unique BLE service UUID.</li> </ol> Artemis MAC address output</figcaption> </figure> Updated connections.yaml (service UUID + MAC)</figcaption> </figure> Connected successfully to the Artemis Nano board in Python:</li> </ol> ble = get_ble_controller() ble.connect() </code></pre> Successful BLE connection</figcaption> </figure> TASK 1</h4> I sent a string from my computer using ECHO. The Artemis constructed an augmented reply and transmitted it back over the TX string characteristic. Artemis: /* * Add a prefix and postfix to the string value extracted from the command string */ case ECHO: // TASK 1 char char_arr[MAX_MSG_SIZE]; // Extract the next value from the command string as a character array success = robot_cmd.get_next_value(char_arr); if (!success) return; tx_estring_value.clear(); tx_estring_value.append("Robot says -> "); tx_estring_value.append(char_arr); tx_estring_value.append(" :)"); tx_characteristic_string.writeValue(tx_estring_value.c_str()); Serial.println(tx_estring_value.c_str()); break; </code></pre> Python: # TASK 1: Send an ECHO command with the string "Hello World!" ble.send_command(CMD.ECHO, "Hello World!") # Receive the echoed string from the RX_STRING characteristic and print it echoed_string = ble.receive_string(ble.uuid['RX_STRING']) print(echoed_string) </code></pre> ECHO output received on laptop</figcaption> </figure> TASK 2</h4> I sent three floats with SEND_THREE_FLOATS and extracted them on the Artemis. Artemis: case SEND_THREE_FLOATS: // TASK 2 float float_c, float_d, float_e; // Extract the next value from the command string as a float success = robot_cmd.get_next_value(float_c); if (!success) return; // Extract the next value from the command string as a float success = robot_cmd.get_next_value(float_d); if (!success) return; // Extract the next value from the command string as a float success = robot_cmd.get_next_value(float_e); if (!success) return; Serial.print("Three Floats: "); Serial.print(float_c); Serial.print(", "); Serial.print(float_d); Serial.print(", "); Serial.println(float_e); break; </code></pre> Python: # TASK 2 : Send a command to send 3 floats to the Artemis ble.send_command(CMD.SEND_THREE_FLOATS, "11.0|-12.3|0.01") </code></pre> SEND_THREE_FLOATS serial output</figcaption> </figure> TASK 3</h4> I added GET_TIME_MILLIS</code>, which replies with a timestamp string formatted as T:<millis></code>. The results of this task are shown in Task 4. I also had to add GET_TIME_MILLIS</code> to cmd_types.py</code> in the right order within the types file. Artemis: /* * Reply with the timestamp in a string */ case GET_TIME_MILLIS: { // TASK 3 unsigned long now = millis(); tx_estring_value.clear(); char buf[MAX_MSG_SIZE]; snprintf(buf, sizeof(buf), "T:%lu", now); tx_estring_value.append(buf); tx_characteristic_string.writeValue(tx_estring_value.c_str()); // Serial.println(tx_estring_value.c_str()); break; } </code></pre>TASK 4</h4> I set up a minimal notification handler in Python to receive strings from the Artemis via BLE notifications. Python: # TASK 4: Create a notification handler def make_notification_handler(controller): def handler(sender: int, byte_array: bytearray): try: msg = controller.bytearray_to_string(byte_array) print(msg) except Exception: msg = bytes(byte_array).decode(errors="ignore") # Strip common C-string padding/line endings msg = msg.strip("\x00\r\n ") return handler </code></pre># TASK 4: Test the notification handler by registering it and reading timestamps handler = make_notification_handler(ble) # ble.stop_notify(ble.uuid['RX_STRING']) ble.start_notify(ble.uuid['RX_STRING'], handler) print("Listening for notifications") ble.send_command(CMD.GET_TIME_MILLIS, "") </code></pre> Notification handler receiving Artemis strings</figcaption> </figure> TASK 5</h4> I ran a short for loop sending 50 GET_TIME_MILLIS</code> repeatedly and used the timestamps received to estimate throughput. I wrote the for loop in the Jupyter notebook; equivalently, it is talking to the Artemis board 50 times via BLE. Python: # TASK 5: Make a loop to send the GET_TIME_MILLIS command 50 times and process it using the notification handler for i in range(50): ble.send_command(CMD.GET_TIME_MILLIS, "") </code></pre> From the printed timestamps, the average inter-message gap was approximately 58.66 ms, corresponding to 17.05 messages/sec. Each message being 9 characters long means its payload is about 9 bytes (1 byte per character), giving an effective payload throughput of approximately: data rate ≈ (messages/sec) × (bytes/message) = 153.43 bytes/sec GET_TIME_MILLIS loop output</figcaption> </figure> TASK 6</h4> I implemented an Arduino timestamp buffer (global array) of size 500 (arbitrary) and added SEND_TIME_DATA</code> to send stored timestamps back to the laptop. You can request it for any integer number of times. It first stores the timestamps in the buffer by running millis()</code> the requested number of times. Then it publishes the buffer results one by one to my computer. I added additional logic for handling the buffer overflow, which sends all the data once the buffer is full, then clears it and restarts the timestamp collection. This method balances the reliability of the data and the availability of data. Again, I had to add SEND_TIME_DATA</code> to cmd_types.py</code> in the right order within the types file. Advantage: Sampling happens locally without waiting for BLE round-trips.</li> Implementation: Store up to capacity, then transmit and restart.</li> </ul> Artemis: /* * SEND_TIME_DATA: Iterate over the stored timestamps and send each as a string */ case SEND_TIME_DATA:{ // TASK 6 /* Serial.print("Sending "); Serial.println(" timestamps..."); */ // Total number of timestamps wanted int interval; // Extract the next value from the command string as an int success = robot_cmd.get_next_value(interval); if (!success) return; int remaining = interval; while (remaining > 0) { // Number to sample in this chunk int n = remaining; if (n > TS_CAPACITY) { n = TS_CAPACITY; } // Fill buffer for (int i = 0; i < n; i++) { timestamps[i] = millis(); } // Send this chunk for (int i = 0; i < n; i++) { tx_estring_value.clear(); char ts_buf[MAX_MSG_SIZE]; snprintf(ts_buf, sizeof(ts_buf), "T:%lu", timestamps[i]); tx_estring_value.append(ts_buf); tx_characteristic_string.writeValue(tx_estring_value.c_str()); } remaining -= n; } break; } </code></pre> SEND_TIME_DATA output</figcaption> </figure> TASK 7</h4> I added a second buffer array for temperature values (same length as timestamps = 500). Both are global arrays. Each index corresponds to a paired measurement. GET_TEMP_READINGS</code> sends T:<ms> , TEMP:<val></code> on each line. It allows the users to request the number of times they want to get the data, and it fetches the current time and temp sequentially, ensuring their values are synchronized. The publishing and buffer overflow logic is handled just like TASK 6. Again, I had to add GET_TEMP_READINGS</code> to cmd_types.py</code> in the right order within the types file. Artemis: /* * GET_TEMP_READINGS: Send paired timestamp and temperature readings */ case GET_TEMP_READINGS: { // TASK 7 // Total number of timestamp and temp readings wanted int interval; // Extract the next value from the command string as an int success = robot_cmd.get_next_value(interval); if (!success) return; int remaining = interval; while (remaining > 0) { // Number to sample in this chunk int n = remaining; if (n > TS_CAPACITY) { n = TS_CAPACITY; } // Fill buffer for (int i = 0; i < n; i++) { timestamps[i] = millis(); tempreads[i] = getTempDegF(); } // Send this chunk for (int i = 0; i < n; i++) { tx_estring_value.clear(); tx_estring_value.append("T:"); tx_estring_value.append(timestamps[i]); tx_estring_value.append(" , TEMP:"); tx_estring_value.append(tempreads[i]); tx_characteristic_string.writeValue(tx_estring_value.c_str()); } remaining -= n; } break; } </code></pre> Timestamp + temperature streaming</figcaption> </figure> TASK 8</h4> Method 1 (Task 5) fetches and sends the data one at a time. It is definitely slower for recording because each sample depends on BLE command/response timing, wasting a lot of time sending and receiving communication. It is, however, useful for simple debugging and low-rate telemetry when real-time interaction matters. Especially, if we decided to have a really large buffer, the data might be stale by the time you get it on the computer side. Method 2 (Tasks 6–7) fetches in volume and sends one at a time. It records data faster because the sampling is local; BLE is only used afterward to transmit stored results. This is ideal for burst logging and experiments where high-rate sampling matters more than immediate real-time feedback. The downside is the delayed availability of the data on the laptop, as I mentioned, and transmission can still be limited by notification throughput. How quickly can Method 2 record data? It is primarily limited by the sensor read and loop overhead on the Artemis. In my test sending 400 requests for SEND_TIME_DATA</code>, recording 400 samples took approximately 13 ms, or roughly 0.03 ms/sample, which is almost 2000 times faster. Memory estimate (384 kB RAM): Each timestamp is 4 bytes (int), and each temp is 4 bytes (float) → 8 bytes per paired sample. Including the global variables I have, which take up 34,152 bytes, but ignoring other overhead, the theoretical upper bound is approximately: 349,848 bytes / 8 ≈ 43,731 sample pairs could potentially be stored in the array before the board runs out of dynamic memory. A more realistic, safe capacity is lower, depending on current global/static memory usage reported by the Arduino IDE. Discussion and Conclusion</h3> I learned how BLE services/characteristics map to read/write/notify behavior and how the Artemis acts as a peripheral device. I also learned to write commands to control the Artemis board using lower-level libraries like RobotCommand.h</code>. Finally, I learned about the limits on how fast the Artemis's temperature sensor can be polled, which is really fast.</li> I implemented an interesting way of handling the buffer overflow for TASKS 6-7, balancing between the availability of data and the reliability of data.</li> The main debugging challenge was making sure that the environment was set up to run the Jupyter notebook. I spent way too long on it when it was just an easy fix. But now I really remember it. Also, I thought about perhaps sending the buffer information in one message, which would depend on how long I could make an EString. Theoretically, I can make it 255 bytes with the Arduino BLE limit, which for TASKS 5-6, is 20-30 messages depending on the length of the timestamp. Realistically, it would not impact the reliability of the data, because the data is already recorded in the buffer, but it can decrease the delay in the delivery of the data.</li> </ol> Collaboration</h3> I collaborated with: Ananya Jajodia. I referenced: Lucca Correia's site for web design and lab writeup. ChatGPT was used for: code debugging + website formatting.

Home

Lab 7: Kalman Filter

Collaboration</h2>
I referred to Jack Long and Aidan McNay's pages for graphing techniques and Kalman Filter C++ architectures. I collaborated with Ananya Jajodia on collecting step response data, and utilized ChatGPT to assist with data visualization and report formatting.</p>

Lab 6: Orientation Control

Objective</h2>
The purpose of this lab is to implement a robust PID controller to manage the orientation (yaw) of the robot. This involves utilizing the IMU to perform in-place rotation using differential drive, while mitigating real-world sensor issues like gyroscope drift and derivative kick.</p>

Collaboration</h2>
I referenced Lucca Correia's site for debugging and testing help. ChatGPT was used to help with some website formatting.</p>

Lab 5: Linear PID Control and Linear Interpolation

Objective</h2>
The goal is to implement a robust linear PID controller to drive the robot quickly toward a wall, stopping exactly 304mm (1 foot) away. Linear extrapolation is used to decouple the high-frequency PID control loop from the slower Time-of-Flight (ToF) sensor data rate.</p>

Position Control Implementation</h2>

Linear Extrapolation</h2>

The Sampling Rate Problem</h3>
The ToF sensor runs at 18-20Hz, but the main PID loop executes hundreds of times per second. Without extrapolation, using stale distance data for 50ms causes jerky movements and discrete derivative steps.</p>

Collaboration</h2>
I collaborated on this project with Ananya Jajodia on troubleshooting my car. I also referenced Aiden Derocher's site for debugging and testing help. ChatGPT was used to help with some website formatting.</p>

Lab 4: Motor Drivers and Open Loop Control

Prelab</h2>

Lab Tasks</h2>

Open Loop Testing</h2> Your browser does not support the video tag. </video>

Collaboration</h2>
I collaborated extensively on this project with Ananya Jajodia and Dyllan Hofflich.</p>
I referenced Aiden Derocher's site for wiring help and PWM testing.</p>
ChatGPT was used for some website formatting.</p>

Lab 4: Motor Drivers and Open Loop Control

Prelab</h2>

Lab Tasks</h2>

Collaboration</h2>
I collaborated extensively on this project with Ananya Jajodia and Dyllan Hofflich.</p>
I referenced Aiden Derocher's site for wiring help and PWM testing.</p>
ChatGPT was used for some website formatting.</p>

Lab 3: Time of Flight Sensors

Lab 2: IMU

IMU Setup</h2>

Accelerometer</h2>

FFT and Low-Pass Filter</h3>
I performed an FFT analysis to characterize accelerometer noise and chose a cutoff frequency for the low-pass filter.</p>

Gyroscope</h2>

Collaboration</h3>
I collaborated with: Ananya Jajodia.</p>
I referenced: Lucca Correia's site for FFT debugging and Sampling data section.</p>
ChatGPT was used for: code debugging + plot generation + website formatting.</p>

Lab 1: Artemis and Bluetooth

Lab 1B</h2>

Collaboration</h3>
I collaborated with: Ananya Jajodia.</p>
I referenced: Lucca Correia's site for web design and lab writeup.</p>
ChatGPT was used for: code debugging + website formatting.</p>

Home

Lab 7: Kalman Filter

Collaboration</h2> I referred to Jack Long and Aidan McNay's pages for graphing techniques and Kalman Filter C++ architectures. I collaborated with Ananya Jajodia on collecting step response data, and utilized ChatGPT to assist with data visualization and report formatting.</p>

Lab 6: Orientation Control

Objective</h2> The purpose of this lab is to implement a robust PID controller to manage the orientation (yaw) of the robot. This involves utilizing the IMU to perform in-place rotation using differential drive, while mitigating real-world sensor issues like gyroscope drift and derivative kick.</p>

Collaboration</h2> I referenced Lucca Correia's site for debugging and testing help. ChatGPT was used to help with some website formatting.</p>

Lab 5: Linear PID Control and Linear Interpolation

Objective</h2> The goal is to implement a robust linear PID controller to drive the robot quickly toward a wall, stopping exactly 304mm (1 foot) away. Linear extrapolation is used to decouple the high-frequency PID control loop from the slower Time-of-Flight (ToF) sensor data rate.</p>

Position Control Implementation</h2>

Linear Extrapolation</h2>

The Sampling Rate Problem</h3> The ToF sensor runs at 18-20Hz, but the main PID loop executes hundreds of times per second. Without extrapolation, using stale distance data for 50ms causes jerky movements and discrete derivative steps.</p>

Collaboration</h2> I collaborated on this project with Ananya Jajodia on troubleshooting my car. I also referenced Aiden Derocher's site for debugging and testing help. ChatGPT was used to help with some website formatting.</p>

Lab 4: Motor Drivers and Open Loop Control

Prelab</h2>

Lab Tasks</h2>

Open Loop Testing</h2> Your browser does not support the video tag. </video>

Collaboration</h2> I collaborated extensively on this project with Ananya Jajodia and Dyllan Hofflich.</p> I referenced Aiden Derocher's site for wiring help and PWM testing.</p> ChatGPT was used for some website formatting.</p>

Lab 4: Motor Drivers and Open Loop Control

Prelab</h2>

Lab Tasks</h2>

Collaboration</h2> I collaborated extensively on this project with Ananya Jajodia and Dyllan Hofflich.</p> I referenced Aiden Derocher's site for wiring help and PWM testing.</p> ChatGPT was used for some website formatting.</p>

Lab 3: Time of Flight Sensors

Lab 2: IMU

IMU Setup</h2>

Accelerometer</h2>

FFT and Low-Pass Filter</h3> I performed an FFT analysis to characterize accelerometer noise and chose a cutoff frequency for the low-pass filter.</p>

Gyroscope</h2>

Collaboration</h3> I collaborated with: Ananya Jajodia.</p> I referenced: Lucca Correia's site for FFT debugging and Sampling data section.</p> ChatGPT was used for: code debugging + plot generation + website formatting.</p>

Lab 1: Artemis and Bluetooth

Lab 1B</h2>

Collaboration</h3> I collaborated with: Ananya Jajodia.</p> I referenced: Lucca Correia's site for web design and lab writeup.</p> ChatGPT was used for: code debugging + website formatting.</p>

Collaboration</h2>
I referred to Jack Long and Aidan McNay's pages for graphing techniques and Kalman Filter C++ architectures. I collaborated with Ananya Jajodia on collecting step response data, and utilized ChatGPT to assist with data visualization and report formatting.</p>

Objective</h2>
The purpose of this lab is to implement a robust PID controller to manage the orientation (yaw) of the robot. This involves utilizing the IMU to perform in-place rotation using differential drive, while mitigating real-world sensor issues like gyroscope drift and derivative kick.</p>

Collaboration</h2>
I referenced Lucca Correia's site for debugging and testing help. ChatGPT was used to help with some website formatting.</p>

Objective</h2>
The goal is to implement a robust linear PID controller to drive the robot quickly toward a wall, stopping exactly 304mm (1 foot) away. Linear extrapolation is used to decouple the high-frequency PID control loop from the slower Time-of-Flight (ToF) sensor data rate.</p>

The Sampling Rate Problem</h3>
The ToF sensor runs at 18-20Hz, but the main PID loop executes hundreds of times per second. Without extrapolation, using stale distance data for 50ms causes jerky movements and discrete derivative steps.</p>

Collaboration</h2>
I collaborated on this project with Ananya Jajodia on troubleshooting my car. I also referenced Aiden Derocher's site for debugging and testing help. ChatGPT was used to help with some website formatting.</p>

Collaboration</h2>
I collaborated extensively on this project with Ananya Jajodia and Dyllan Hofflich.</p>
I referenced Aiden Derocher's site for wiring help and PWM testing.</p>
ChatGPT was used for some website formatting.</p>

Collaboration</h2>
I collaborated extensively on this project with Ananya Jajodia and Dyllan Hofflich.</p>
I referenced Aiden Derocher's site for wiring help and PWM testing.</p>
ChatGPT was used for some website formatting.</p>

FFT and Low-Pass Filter</h3>
I performed an FFT analysis to characterize accelerometer noise and chose a cutoff frequency for the low-pass filter.</p>

Collaboration</h3>
I collaborated with: Ananya Jajodia.</p>
I referenced: Lucca Correia's site for FFT debugging and Sampling data section.</p>
ChatGPT was used for: code debugging + plot generation + website formatting.</p>

Collaboration</h3>
I collaborated with: Ananya Jajodia.</p>
I referenced: Lucca Correia's site for web design and lab writeup.</p>
ChatGPT was used for: code debugging + website formatting.</p>