Currently, the stick does attempt to move towards equilibrium, but will ultimately tip over on its own. In our most recent trials, the cause of this is imbalance is overshooting the equilibrium, which is likely due to the relatively low response rate. Despite not having met all of our criteria, we believe that we made significant progress given our minimal experience in controls and the ambition of the project itself. This project was driven through the amalgamation of our knowledge from our classes at UC Berkeley, where we utilized knowledge from classes such as EECS 16B, EE 120, and EECS 149.
Throughout this project, we experienced the engineering life cycle, from various aspects of designing to integration and testing. We learned that it was imperative to design a minimum viable product in order to test and iterate as many times as possible. We discussed our failures analytically and made improvements based on data and intuition. Moving forward, we plan on designing a simulation of our system using Simulink and potentially Gazebo. Although we did this to save time, we learned that tuning PID values without a simulation was counterproductive since it forced us to rely on just our formulas and experimentation. In addition, we want to communicate IMU data using ROS and interface the microcontroller with a Raspberry Pi in order to realistically emulate what is done in research and industry.
One major setback was the late delivery of the Nidec 24H motors, which pushed back the timeline for developing code to interface with the motor as well as hardware design and integration. Some of the details of the motor interface were missing, meaning the specifics of the motor behavior in relation to software was determined by trial and error. We also had to revise our CAD after receiving the motors since the ones we obtained had a gear attached to it and different size screw hole than we expected.
Also, as mentioned previously, the combination of a single-threaded Arduino, the high-frequency Nidec 24H motors, and the need for real-time response restricted our ability to optimally control the system. There are certainly ways to combat instability of the system with smoother motion using incremental control methods, but we also certainly cannot ignore what we lack in our current set of electronics.
On presentation day, Professor Sreenath suggested that we try different stick lengths. Since then, we tested two 3D printed stick lengths: 150 cm and 190 cm. We learned that the 190 cm one worked considerably better since the longer length provided more torque to the system. We also tried a 300 mm stick made out of 8 standoffs screwed together. While the system had a lot of torque, this created a lot of instability since our DIY stick had a lot of bending motion.
Fangyu Wu suggested that we try heavier wheels since this was another way to increase torque. Using all slots in our wheel, we added 9 nuts and bolts which increased the mass of each wheel by 45 grams. This indeed provided more torque but also introduced a lot of instability to our system. Jay Monga recommended that we reconsider our feedforward term, so we reperformed calculations detailed in the Design section and implemented it into our system.
Also, switching to the ESP32 microcontroller would help us react better to the real-time changes of the system and would be preferable over the admittedly hacky solution of using Arduino interrupts.
We would like to thank the following people for their support:
Professor Sreenath, for his encouragement and assistance in choosing this project topic;
The EECS 106A content team, for designing inverted pendulum problems and giving us the mathematical background necessary to pursue this project;
The EECS 106A lab TAs, for designing Lab 7 and introducing us to PID and controls;
Our fellow classmates, who were patient with us as we repeatedly used the 3D printer in the Supernode lab;
Everyone else in EECS 106A, who created a welcoming learning environment for us and enabled us to pursue an ambitious project.