Presentation 1 - Tumbller Bot Initial Progress

Introduction
For this project we are modifying code of the Elegoo Tumbller bot to allow us to control its movement with a joystick. The first step we took to achieve this is to simply remove all of the excess code from the source code provided on Elegoo's website. Then, I designed two small Finite State Machines (FSM), one for the mode controlling the behavior and the other for the motor speeds.

Design
First step was to reduce a lot of the code bloat, most of which was to ensure cross-compatibility. I reduced the original 20 files to 7, including the .ino file. All of the functions controlling the car is wrapped by a class named Controller, and all contained in CarControl.h/.cpp. I kept most of the original code in BalanceCar.h with small modifications to account for removing the MsTimer2, PinChangeInt, and I2Cdev libraries (As well as most of the MPU6050 library). The pins used for the encoders are pins 2 and 4, the latter of which isn't an external interrupt pin which is why the original code contained the PinChangeInt.h library. I originally intended to keep that library for ease's sake, but that library isn't well written. Multiple definition macros were outside of the header guards (Which are missing from most of the .h files in the source code) as well as everything being defined in the header file. So even with the former issue fixed, the latter problem prevented me from being able to easily incorporate it into my code. However, modifying the ATmega328P's registers, shown in Fig. 1, to enable the timing, external, and Pin Change interrupts is pretty trivial. The ISR definitions are shown in Fig 2.

I originally had the code written to use a more object-oriented FSM design pattern, but it ended up causing more problems than it was worth. Because of this, I decided to rewrite most of the code 1 day before the presentation and instead used jump tables to implement 2 smaller, separate FSMs. This allowed me to wrap the main control loop into a single function as well as have more control over how the car behaves.

Figure 1 - Setting the registers to enable the carBalance() function to be called approx. every 5ms and PC/External interrupts for the encoder pins.

Figure 2 - ISR definitions

Figure 3 - .ino code

Figure 4 - Definition for the ctrl.run() function in Fig 3.

Figure 5 - Jump tables used in run().

Figure 6 - Code used to read needed data from MPU6050, modified from the original to pass a reference to a struct.

Test Results
The code is very close to being able to properly manipulate the car's movement. At the initial start, the car does balance itself properly. However, there are two main problems that occur when the car tries to execute the movement test. The main problem is that no matter how small the value setting_car_speed is set it still full sends the motors. Additionally, while it does move forward and backward, it isn't keeping its balance while moving because of the aforementioned issue. There are also some minor issues with it idling while stopped in order to keep balanced, but this shouldn't be too difficult to fix since I believe I just need to change the logic in the stop function.

Next Steps
For the next week, the first big task is simply getting the motion test properly working. This shouldn't take too long as I am narrowing in on the cause of the issues I'm having. Next is to work on integrating the joystick inputs. As I have written the code with this change in mind, integrating joystick control in of itself will be easy so long as the issues with movement is fixed. So, most of the work with this task will simply be implementing the wireless communication between the joystick and the car. I am thinking of using ESP32s for the wireless connection since the car itself has quite a few additional pins to allow for serial communiction, I2C, and powering additional peripheral devices.

Appendix .ino code used.
Code showing MPU6050 function member definitions and the I2C helper functions preserved.