Presentation 2 - 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
Last week's problems with the car's motors going full bore was caused by the Serial prints I was using for debugging were taking up too much processor time, delaying the carBalance() interrupt, since the Serial library is interrupt driven. Commenting out the serial prints was the only thing I did and the car balanced perfectly. Afterwards, I did make a slight modification the timer2 interrupts, using the CTC mode instead of normal mode.
I originally planned to use the NRF24L01 2.4GHz wireless modules we used previously, but I accidentally grabbed very similar looking ESP8266s. Since I had a few ESP32s lying around my house, I decided to use those to wirelessly communicate the joystick data to the Tumbller bot. Since I only needed one way communication to the nano, I simply plugged the ESP32's TX2 pin to the nano's RX pin without using any sort of level shifting since 3.3V is enough to trigger a logic high for 5V logic. In order to reduce the amount of time spent on decoding the serial data, I am using the highest baud rate achievable with no data loss between the two. Through testing I verified that, surprisingly, the ATmega328P of the Nano is able to drive 2Mbps, the max baud rate on the 16MHz clock according to the datasheets, with no data loss observed on the serial monitor. With the ESP32, it, in theory, has a max baud rate of 5Mbps. However, the highest baud rate I was able to observe on the serial monitor was 1MBps; half of the Nano's highest observable baud rate. Since the clock driving serial communication has a varying percentage of error, as well as different tolerances to timing error, finding the highest baud rate achievable was a bit time consuming. The highest baud rate I was able to have succesful communication seems to be 460800Mbps, far lower than I had initially hoped could be achieved. However, since there seems to be slight problems with how the received data is processed by the nano it is possible that there is still data integrity issues at the current baud rate of 460800Mbps.

Figure 2 - Function for the receiver ESP32 to handle translating the data and sending it over Serial to the Tumbller's nano.

Figure 3 - Tumbller bot with ESP32 connected to allow wireless communication.

Test Results
The car is able to balance pretty well now. One small issue is that if one of the wheels starts to loosen, the extra play in the wheel causes the car to over-correct its balancing and starts shaking the wheel that is loose more and more. The joystick control is close to working. I want to have the data directly translated into the wheel, but it seems to be not quite working so far. Instead, I modified it to use the motion FSM to control the movement. It is able to turn left and right somewhat well but both positive and negative x direction on the joystick results in the car moving backwards despite the forward/backward motion functions have opposite values.

Next Steps
For the next week, I simply have to fix any bugs with processing received serial data as well as finely tuning the baud rate to ensure that Serial communication is taking as little of the processor's time as possible to ensure the car balancing interrupt runs as smoothly as possible.