I have to confess that I dont know why I didn't consider this up front as it does make life a lot easier when setting up the robot. I have produced a YouTube video that has a walk through of the code changes, I will link it at the bottom of the article, however to allow us to tune the PID and other settings over Bluetooth there are a few things to be considered.
- How we do retain any changes made after changing the setting values?
- How do we segregate running and tuning modes?
- How do we actually make sure the commands are responded to appropriately?
Well to answer the first question. I decided the best way would be to implement saving and restoring settings from the microcontroller EEPROM. This then allows the values to be premanently stored after changes are made, and be retrieved on the next startup. I have produced a tutorial on how to use the EEPROM on the Arduino, it can be found at the link below. Please take the time to review this, in it I discuss an inline style mode and also using a class to encapsulate the settings code. I have based the new Settings class in the Robot on the code discussed in that tutorial and simply extended it to provide additional functionality.
In looking at the second question of segregating run and tuning modes, after some trial and error I decided to implement two new states in the State Engine. The two new modes allow for the slightly different requirements for each mode. it also allowed the commands to be better handled when in the different states.
The two new modes are Tune_Starting and Tune_Balancing. The majority of the actual balance code is duplicated from the Starting and Balancing states however at the beginning of each state any information received over the serial port is analysed to determine if it is valid and how it needs to be handled. Inthe Tune modes I also restrict certain commands that could cause issue when adjusting tuning parameters.
So to the last question, we need to be very careful when using the serial port, as the serial port as we need to be continually processing our balance code. If we were to use thge serial port as a stream device the effect of waiting for a complete command could well upset the balance algorithm. In fact during testing this was indeed the case. This meant I needed to treat any data on the serial port on a character by character basis. When a character is received it is analysed to determine if it is valid for the state and if it is indded a setting command. If it is indeed part of a setting command the command string is built up and once a carrige return character is received the completed command is processed accordingly.
Well that is a run down on my thinking when it came to making this change to the code, please take a look at my YouTube video below as I discuss the changes in more detail. The supporting iOS App can be installed from the Apple App Store at the link below:
As always please like and subscribe. It really does help me out if you do and if you have any comments, good, bad or whatever I would love to see them. Also if you do make a version of the robot I would love to see the results.