Final Project
Team Number: 8
Team Name: Team Integr8!
| Team Member Name | Email Address |
|---|---|
| Anjali Kalanidhi | anjk@seas.upenn.edu |
| Nevan Sujit | tsnevan@seas.upenn.edu |
| Sebastian William Thomann Studholme | sthomann@seas.upenn.edu |
GitHub Repository URL: https://github.com/upenn-embedded/final-project-s26-t8
GitHub Pages Website URL: https://upenn-embedded.github.io/final-project-s26-t8
Final Report
1. Video
2. Images

3. Results

3.1 Software Requirements Specification (SRS) Results
| ID | Description | Validation Outcome |
|---|---|---|
| PWM Control | The system will generate PWM signals from the microcontroller to control motor speeds smoothly and efficiently. | Confirmed, the PWM outputs were checked via print statements and by reading an oscilloscope of the output. We had some hardware issues with this aspect, but the software worked very well. We had two different stepper motors with two different stepper motor drivers, so we had to specifically tune each code to work for each stepper motor driver, and then test and validate the PWM output coming out of each driver. |
| Analog Input Processing | The system will read and process analog signals from the potentiometer using the onboard ADC to determine input magnitude. | We decided to use a joystick rather than a potentiometer because we felt the fact that it allowed the user to move the chassis in real time instead of simply picking a location for the chassis to end up at improved the user experience so it was easier for them to better determine which exact spot the chassis ended up at. Using the joystick also let us include variable speeds depending on how far the joystick was pushed. This system worked correctly, as we were able to check via print statements that showed us the numerical value the system was translating this input to PWM. Joystick validation video |
| Encoder Processing | The system will decode signals from the rotary encoder to track position and direction. | Works very well, we were able to confirm this is working accurately by manually measuring an angle and then using the rotary encoder and follower wheel to see if the same value is generated via print statements ![]() |
| Integration Computation | The system will keep track of rotary encoder input and sum values to calculate integral | Works well, we used print statements to see how the software sums up the positions over time, We estimate there is an error of up to 10% just by accounting for the inaccuracies of the wheel size and other mechanical limitations, but the software does its job properly. |
| Stepper Control Logic | The system will generate step and direction signals to control the stepper motor position based on the input function | We printed the out the supposed location of the stepper motor and then manually checked how far the stepper motor moved the chassis to determine if the signals were correct. This process required some tuning. |
| DC Motor Control Logic | The system will adjust DC motor speed and direction using PWM signals to maintain consistent disk rotation. | Works very well, we checked that the correct PWM signal was being generated by the software via an oscilloscope |
| Timing Control | The system will use hardware timers to maintain a fixed sampling rate for integration and motor updates. | First, we attempted to use RTOS to schedule all of the tasks needed to make this system functional. However, we ran into issues with memory space on the ATMega, so we had to switch to using ISR’s instead. This ISR system works by having a hardware timer (Timer1 in CTC mode) generate an interrupt at a fixed rate of about 60 Hz, and this ISR acts as the high-priority control loop. Inside the ISR, the program reads the encoder, updates the running integral, samples the ADC, and adjusts the motor PWM and direction, ensuring these operations execute consistently. Meanwhile, the main loop runs independently as a low-priority task, handling slower operations like updating the LCD display and formatting output, even though it includes blocking delays. We ensured that this system worked by looking at an oscilloscope to see which task was happening when periodically. |
| Display Software | The system will update the LCD via I2C to display input values, output values, and system status in real time. | Works well, we were simply able to validate this system works by checking the screen and ensuring that what we wanted to show up on the screen was actually showing up. Earlier on, we ran into some issues where the screen was not updating properly, or would turn blank after a certain amount of time, but we realized this was because the system did not have enough time to properly initialize, so by adding delays into our code, we were able to fix this issue. |
3.2 Hardware Requirements Specification (HRS) Results
| ID | Description | Validation Outcome |
|---|---|---|
| Power Supply Hardware | The system should include a 9 V battery and a buck converter to provide a stable 5 V supply to all electronic components. | We were unable to meet this requirement due to changes in the power requirments for the system. We initially thought our stepper motors would require 9V, but the more heavy Nema 17 motor required 24V. As a result, we were not able to order a 24V power supply in time for the demo, so we used the voltage supply for all voltages needed |
| User Input Hardware | The system should include a slider potentiometer that allows the user to manually define the input to the integrator. | Works well, we were able to check what the input is by measuring the distance the chassis moves. Our input is through a joystick instead of potentiometer, and the input signal is also relative to the maximum y values we set (the range being -2 to 2 for the final product of this project), so there were some limitations with how accurate this input could be based on what function the user actually wishes to input, but that is more of a matter of mechanical limitations rather than hardware issues. |
| Disk Rotation | There will be a DC motor-driven rotating plate mechanism that rotates at constant speed to represent time | The disk rotation was quite easy to accomplish and validate, as we were able to use an oscilloscope to see the PWM signal, and then manually count how long it takes the disk to complete a rotation to ensure that the motor driver and motor were working properly. We ended up changing this motor from a DC motor driver to a stepper motor, as that allowed us to rotate the plate at a constant speed more easily within the software stack |
| DC Motor Driver | The system will include a motor driver to control the speed of the DC motor using PWM signals. | We had a lot of issues with this motor driver, as the driver fried twice. The first time, we swapped out the driver and the second time, we unsoldered and resoldered a new chip onto the motor driver, fixing these issues. We think this issue was caused by abruptly giving the motor driver power and turning it off when testing. Similar to the requirement above, we were able to validate that the output of this motor driver was correct with an oscilloscope, and this aspect of the project worked very well. Below is the PWM output for the constant plate stepper motor: ![]() |
| Stepper motor function input | There will be a stepper motor-driven mechanism that adjusts the location of the chassis based on the input function | For the most part, this system works quite well. However, in the beginning we ran into many issues with the stepper motor stalling when we gave it power, and we spent a lot of time debugging that issue. Eventually, we realized it was due in part to torque issues caused by the clamp connecting the motor to the rod it was supposed to be turning, so we loosened the rod and attached it with glue (it could be unglued as well after use!). |
| Stepper Motor Driver | The system will include a stepper motor driver to provide precise position control via step and direction signals from the microcontroller. | We had some issues with this stepper motor beause we realized the current limit for the motor driver was set too low, causing the Nema-17 motor to stall. By increasing the potentiometer on the driver, we were able to fix this problem. This system worked pretty well, though we estimated there was likely a 10% error due to mechanical issues that happened within the system after the stepper motor driver supplied the PWM signal to the motor. We checked that the correct signal was being supplied via an oscilloscope Stepper motor driver validation |
| Output Shaft Sensing | The system will include a rotary encoder mechanically coupled to the output shaft so that shaft rotation can be measured electronically. | Using the rotary encoder worked very well, especially once we were able to solder the pins properly. We had a few mechanical issues with placing the rotary encoder so it did not move, but overall through testing and mechanical tuning we were able to ensure this process works well through print statements. |
| Display Hardware | The system will have an LCD display connected through I2C to present system information to the user during operation. | We were able to get this system working well so that it displays the integral function as well as the value of the integral. We originally had some overflow issues with the display, causing it to blank out, but by switching from an RTOS system to one dirven by ISR’s and adding in proper delays for startup, we were able to fix this problem. |
4. Conclusion
Overall, we found this project to be immensly fulfilling and each felt that our we gained very valuable skills not only in embeded C, but in learning how to plan and put a whole project together, learning which parts to pick and what to account for when picking parts, and how to CAD, laser cut, and understand how to integrate software, electrical, and mechanical parts together to make a complete project.
Some important things we learned about were knowing which software techniques to use when (RTOS may have been better at scheduling, but the memory limitations of the ATMega showed us that using ISR’s was the better option). We also worked on many different parts of the code at once, and then had to integrate them all together, which allowed different members of the team to always have something to do, but led to some changes having to be made during software integration to account for the fact that different people writing code may affect the efficiency of the system. We also got good at learning how to diagnose if a problem was due to software, electrical, or mechanical components, like when our Nema 17 motor was stalling (a mix of electrical and mechanical) or when the LCD screen was not displaying properly (software). A big unexpected challenge for us was putting all the mechanical components together. We understood that this project was very mechanical-heavy, but underestimated how many clamps and chassis’ would break, had a lot of trouble figuring out tolerances (tolerances for laser cutting with wood vs acrylic vs 3D printing led to a lot of trial and error), and didn’t really account for the time it takes to lasercut/print. As a result, on the morning of our demo, the threading in our chassis that allows the Nema-17 to move the plate left and right wore down, and we were scrambling to print a new one for our demo. Overall, we felt that we met pretty much all of our software/hardware requirements, but the mechanical aspects of our project were what was holding us back from making it even more complete. Our project is a great prototype, but next time, designing with mechanical integration in mind earlier could help us a lot in minimizing error. Our next steps for this project would be to redesign our actual frame so it fits together better and to consolidate our power supplies with a buck converter so we can power the entire system with a single 24V power supply.
References
We first learned about the mechanical integrator from a Youtube video titled The Mechanical Integrator - a machine that does calculus by Jack Monaco. We wanted to try and build this project for ourselves, adding complexity with the LCD screen as well as user input. We emailed the author of this video to ask him for the CAD model of his design to use as a basis for ours, but found that his design was pretty underdeveloped/incomplete. Instead, we used his design as a basis to create our CAD model.
Final Project Proposal
1. Abstract
A mechanical integrator is a device that physically computes the integral of a function by converting a changing input into accumulated motion over time. Historically, mechanisms like these were used in early analog computers to solve math problems before modern digital computers were available. In this project, we are building a microcontroller-assisted mechanical integrator that demonstrates this concept in an interactive way. A slider potentiometer allows the user to control a time-varying input value, which is read by an ATmega328P microcontroller. The system drives a motor that changes speed as an analog to the function value over time and the mechanical integrator uses the motor encodings to calculate the accumulated distance travelled over time, which is an analog to an integral. The microcontroller will output the behavior of the input and the resulting integral on a small LED display and on the serial plotter.
2. Motivation
We are building our mechanical integrator to create a more computation-efficient way to solve integrals, particularly because the ATMega328P is not well-suited for computing complex mathematical problems. This project is interesting because we are building a mechanical integrator, a device that was historically used to calculate complex integrals, but updating it with the modern firmware capabilities of the ATMega to show that analog based technologies still have their merits.
3. System Block Diagram

4. Design Sketches

5. Software Requirements Specification (SRS)
5.1 Definitions, Abbreviations
Here, you will define any special terms, acronyms, or abbreviations you plan to use for hardware
5.2 Functionality
| ID | Description |
|---|---|
| PWM Control | The system will generate PWM signals from the microcontroller to control motor speeds smoothly and efficiently. |
| Analog Input Processing | The system will read and process analog signals from the potentiometer using the onboard ADC to determine input magnitude. |
| Encoder Processing | The system will decode signals from the rotary encoder to track position and direction. |
| Integration Computation | The system will keep track of rotary encoder input and sum values to calculate integral |
| Stepper Control Logic | The system will generate step and direction signals to control the stepper motor position based on the input function |
| DC Motor Control Logic | The system will adjust DC motor speed and direction using PWM signals to maintain consistent disk rotation. |
| Timing Control | The system will use hardware timers to maintain a fixed sampling rate for integration and motor updates. |
| Display Software | The system will update the LCD via I2C to display input values, output values, and system status in real time. |
6. Hardware Requirements Specification (HRS)
6.1 Definitions, Abbreviations
Here, you will define any special terms, acronyms, or abbreviations you plan to use for hardware Plate: The bottom, flat, circular disk that is rotated by a motor to represent the x-axis. Follower: the small wheel attached to a rod that spins as a result of the plate rotation
6.2 Functionality
| ID | Description |
|---|---|
| Power Supply Hardware | The system should include a 9 V battery and a buck converter to provide a stable 5 V supply to all electronic components. |
| User Input Hardware | The system should include a slider potentiometer that allows the user to manually define the input to the integrator. |
| Disk Rotation | There will be a DC motor-driven rotating plate mechanism that rotates at constant speed to represent time |
| DC Motor Driver | The system will include a motor driver to control the speed of the DC motor using PWM signals. |
| Stepper motor function input | There will be a stepper motor-driven mechanism that adjusts the location of the chassis based on the input function |
| Stepper Motor Driver | The system will include a stepper motor driver to provide precise position control via step and direction signals from the microcontroller. |
| Output Shaft Sensing | The system will include a rotary encoder mechanically coupled to the output shaft so that shaft rotation can be measured electronically. |
| Display Hardware | The system will have an LCD display connected through I2C to present system information to the user during operation. |
7. Bill of Materials (BOM)
A 10k slider potentiometer will serve as the primary input as it will be used as the analog for function value over time. The potentiometer will be connected to an ADC pin on the microcontroller so that the system can read the input value.
The mechanical integrator requires two motors. A DC gear motor will rotate the time disk, providing the constant motion needed for the integration process. This motor will be controlled using a motor driver, which allows the microcontroller to regulate motor speed using PWM signals. A stepper motor will be used to control the position of the follower mechanism. A stepper motor is needed here as we need precise position control and it will be driven using an EasyDriver stepper motor driver.
To measure the output of the integrator, a rotary encoder will be attached to the output shaft. The encoder will generate pulses that the microcontroller can count using interrupt pins to determine how much the shaft has rotated.
Finally, an LCD display will be used to display the integral value. The display will communicate with the microcontroller using the I2C interface and will show information such as the input value and the integrated output.
8. Final Demo Goals
On demo day, the device will be demonstrated on tabletop. A user will control the input function using the slider potentiometer, which changes the motor speed over time. As the slider is moved, the mechanical system will compute the integral through its physical motion, while the microcontroller reads and visualizes the output integral on an LED display.
During the demonstration, several simple input patterns representing basic functions will be shown, such as holding the slider at a constant value (y=c), changing it linearly over time (y=mx), and sinusoidal functions. These examples will illustrate how the output accumulates and how the integral changes based on the input. The main constraints for the demo are ensuring that the mechanical components are properly aligned and calibrated.
9. Sprint Planning
| Milestone | Functionality Achieved | Distribution of Work |
|---|---|---|
| Sprint #1 | Build the entire project on CAD. Since this project requires a fair amount of laser cutting + 3D printing, we want to make sure that we design all those parts before we design anything physically. Not only should the entire design, including the manufactured parts and electrical components be in our CAD design, but we also want to create simulations in our design for how the mechanisms should move. | Anjali CAD’s the plate & things it is connected to, Nevan CAD’s the follower and things it is connected to, Sebastian CAD’s all integration |
| Sprint #2 | Following this our second milestone will be to both print and assemble the manufactured parts with the electrical components, and then program the MCU to take in the potentiometer input and output the correct PWM signals and take the motor’s encodings to calculate the integral. With these two milestones, we will have essentially finished building our project. | Anjali handles printing of parts and mechanical side of things, Sebastian works on software, Nevan works on electronics. Everyone is working together to integrate, so tasks are not as clear cut |
| MVP Demo | Potentiometer input leads to function displayed through serial monitor, integral output, as well as LCD showing the integral numerical value. | Anjali works further on mechanical/software integration, Sebastian and Nevan finish coding. Most of this week will be spent tuning device and making sure it works well. |
| Final Demo | if time permits we want to build a way for the user to draw rather than use a potentiometer to create their function. The user would draw their desired function that they want to integrate on a display and then this drawing gets converted to a list of numbers that the MCU can then read to control the PWM signal to input into the motor. The output could then also be displayed in the serial as the distance travelled by the motor over time. | Sebastian CAD’s mechanical components, Anjali and Nevan work on software/electrical updates to make new features work. |
This is the end of the Project Proposal section. The remaining sections will be filled out based on the milestone schedule.
Sprint Review #1
Last week’s progress
We have CAD’d most of the model for the project and ordered all the components we need. We finalized which components we wanted to go with, including picking which motors to use and deciding which components in Detkin we can use and which components we want to order. We have finalized the CAD design for the wheel and for the connectors between the frame and the rods. We have begun laser cutting and are planning on finishing assembly physically integrate our electronic components into the design next week. We still need to figure out how to add wheels to the chassis that the plate spins on and how to connect the rotary encoder to the follower wheel and shaftf, so those will be mechanical challenges we need to figure out next week.

Current state of project
We have a pretty solid foundation for this project. We understand how it works mechanically, which parts should be connected to one another, and how we want to integrate electronics. We have all parts purchsed, and at this point we just need to focus on finishing the mechanical parts and assembly as soon as possible so we can focus on hardware.
Next week’s plan
Finishing printing and assembly, create a plan for how we are physically going to wire up our components, and create system diagrams for our code so we can integrate everything completely the week after. | Assignee | Task | Estimated time | Finished when… | | ———| —–|————— | —————- | | Nevan | CAD and print the chassis | Two hours | The chassis is printed | | Sebastian | Connector between rotary encoder and follower shaft wheel | Two hours | Connector is printed and glued to rotary encoder and shaft | | Anjali | Connect follower wheel to shaft to bearings to rotary encoder | 1 hour | Entire top piece is connected | | Nevan | CAD and print base | Two hours | Base is printed | | Anjali | CAD and print wheels | Two hours | Wheels are printed and connected to chassis as well as track | | Sebastian | Final assembly | Two hours | Connect all pieces together, motors are placed in correct location |
Sprint Review #2
Last week’s progress
We completely finished CADing and most of our parts are printed. We had to alter tolerances because we made some of them too tight, so we are currently just waiting on those last parts to print. Most of our electronics have come in as well so we have begun to write code as well as assemble. We are splitting each of the components into separate code segments and then planning on integrating all the code together. The code for the follower wheel encoder, which actually calculates the integral, is complete.

Current state of project
We have code for the rotary encoder that tells you the correct integral value, and most of the components assembled together, we just need to add them to the frame.
Next week’s plan
Finishing coding is top priority, then working on assembly. There are lag times in getting our mechanical parts finished, but since we have the motors and drivers we need, we can work on writing code in the meantime to make integration go smoother. Because the mechanical aspect of this project is taking longer than expected, we are focusing on getting the integral to work with a manual function input, and then will add user input the following week. | Assignee | Task | Estimated time | Finished when… | | ———| —–|————— | —————- | | Nevan | print the frame | one hour | The frame is printed/ made sure all componenets are correct sizes/fit | | Sebastian | assemble the frame | two hours | mechanical frame is fully complete with all separate components | | Anjali | integrate electronics | 2 hour | all electronics are in the frame | | Nevan | code the big stepper motor/y axis | five hours | the rod moves in tandem with the y axis of a function | | Anjali | code the time/constant plate, integrate all code together | five hours | all code is complete | | Sebastian | final integration | five hours | Connect all pieces together, motors are placed in correct location, fully integrated together | | Nevan | Code LCD Screen output | two hours | LCD properly displays what integral value we want it to |
MVP Demo
System block diagram:

Hardware explanation: The hardware system is organized around the ATmega328P microcontroller, which serves as the central controller coordinating power, sensing, and actuation. A 24 V power supply provides the primary energy source, which is stepped down to 5 V using a buck converter to safely power the microcontroller and low-voltage peripherals. User input is provided through a joystick connected to an ADC pin. The ATMega processes this input and turns it into PWM outputs for the motors. One stepper motor (turning the plate) establishes the time base by driving the plate mechanism, while another stepper motors (the heavy duty NEMA 17) is used to represent the y axis of the function input. This movement turns the follower wheel, which turns the rotary encoder connected to digital pins (PD2/PD3) which read the angle position. The ATMega then processes this data and sums up the overall change in angle to find the total integral. An LCD display communicates with the microcontroller over I2C, enabling real-time visualization of the integral as well as its value. The system operates in a closed-loop style at the user level: the user sets an input via the potentiometer or joystick, the microcontroller processes this input and generates appropriate control signals, the motors actuate the mechanical system, and the resulting motion is observed through the encoder feedback and displayed on the LCD.
Firmware implementation: The firmware is structured into modular components that separately handle sensing, user interaction, and motor control while remaining tightly coordinated through the main control loop. One module manages the rotary encoder and LCD output, where interrupt-driven inputs from the encoder (on PD2/PD3) are used to track position or system output in real time, and this information is formatted and transmitted over I2C to the display for user feedback. A second module controls the NEMA 17 stepper motor responsible for the y-axis (input function), generating precise step and direction signals to map the user-defined input—set via the potentiometer or joystick—into accurate vertical motion. The third module governs the stepper motor driving the plate mechanism, which acts as the x-axis (time base) by running at a constant, calibrated speed to ensure a uniform progression of time. Together, these modules create a synchronized firmware architecture where the time axis advances steadily, the input axis responds dynamically to user control, and the system state is continuously measured and displayed, effectively implementing the mechanical integration behavior.
Software Requirements Specifications: The software is designed to integrate sensing, computation, and actuation into a single cohesive system. Analog input processing is implemented thorugh the joystick, allowing user-defined inputs to be continuously sampled. Rotary encoder processing is tightly coupled with the integration computation, enabling real-time calculation of the system’s output within the same execution flow. While the integration logic is functional and produces correct mathematical behavior, further tuning of variables is required to improve accuracy and stability. During development, stack overflow issues were encountered, indicating memory constraints that required optimization of function usage and data handling. Stepper motor control for the input axis and time axis are both operational, though additional tuning is needed—particularly for incorporating encoder feedback to correct accumulated positional errors over time.
From a timing perspective, a structured scheduling approach through RTOS has been implemented to reliably sequence encoder reading, integration computation, and LCD updates, ensuring consistent real-time performance. However, this timing framework still needs to be extended to both stepper motors. The display system is complete, providing clear real-time feedback of system state, including input and output values. Overall, the software is functionally complete but requires further calibration and optimization, as well as full integration of all systems through RTOS.
Hardware Requirement Specifications: The hardware implementation centers on the ATmega MCU. Power is currently supplied through multiple working sources, so distribution architecture still needs to be consolidated. User input is provided via a joystick that feeds analog signals into the MCU, where the ADC reliably converts them into digital values for processing. The rotary encoder is functioning well and provides consistent, accurate measurements, while the disk rotation mechanism for the time axis is also operating as expected. The display hardware and stepper motor driver are both stable and performing reliably within the system.
On the actuation side, stepper motor drivers are generally functional but require further tuning, particularly for the NEMA 17 motor, which is experiencing jitter and lag. These issues are mostly caused by mechanical factors such as friction, misalignment, or load inconsistencies in the mechanism. Overall, while the core hardware components are working, final performance depends on improving both driver tuning and mechanical integration to reduce lag and ensure consistent motion.
Risk mitigation: To mitigate the risk of high voltage damaging components or overheating motors, hardware safeguards such as current limiting, proper driver configuration, and protective circuitry (e.g., fuses or thermal shutdown features) are implemented to prevent excessive power draw. Mechanical failures are addressed by reinforcing all structural components using secure fasteners like screws instead of adhesives, ensuring greater durability and stability under load. Together, these measures improve both electrical safety and mechanical reliability of the system.
Next steps: The next steps focus on fully integrating the mechanical and control subsystems into a single cohesive system, ensuring that the firmware and hardware operate seamlessly together. Mechanically, the device will be assembled and reinforced, while the power system will be standardized to a single wall supply for simplicity and reliability. Additionally, debugging efforts will target stepper motor jittering to improve motion smoothness and overall system performance.
