Prior to this testing the robot perfromcance can be summarised: robot could balance for a maximum of about 20 seconds but was very inconsitent, the robot ususally failed because it started to rotate (nothing in the code was telling it to rotate), sometimes the robot would stay at top dead centre then just appear to give up; ie it was not just an issue of a poorly tuned PID controller, there was some undesired behaviour occuring. The code conducted a calibration sequence whilst supporting the robot vertically and would just start trying to balance once the callibration sequence was complete.

Conducted a few hours of testing and adjusting in an attempt to get the robot balancing. I tested in the iForge makerspace using a string harness (to stop the robot falling over) and logging some of the values to the sensor and control values to the serial monitor. Summary follows:

• Added code to allow the calibration sequence to run whilst the robot is on its side then when picked up the robot will start balancing if the accelerometer detects that the robot is upright (see the linked project YARB to understand what I mean). I managed to implement this but there were problems when the robot actually started balancing where the robot accelerated very agressively immediately and became unstable. Investigation through the Serial Monitor revealed that this new calibration procedure resulted in an inaccurate gyro angle (+4 degrees). For the time being I have disabled these lines of code and reverted to the start up procedure described above.
• Power source was increased from 11.4v to a 15.5v LiPo. This was done in attempt to increase the torque delivered by the motors incase this was the reason for the robot "giving up" (not having the required torque and therefore stalling).
• Following the power increase I tried to tune the PID values again to some success. The best balancing time was around 30 seconds but the robot suffered from the same problems of rotating. The motors were definitely delivering more torque so the robot failed less frequently due to "giving up" somewhat confirmed my suspicions of a lack of torque.
• A second attempt to prevent the robot "giving up" was setting a limit on the lowest permitted motor speed (other than when at top dead centre) because the robot always seemed to fall when the serial monitor reported a sudden very low motor speed. The effect of adding this meant that the robot consitently failed due to rotation. Thus the rest of the testing was trying to figure out why the robot kept rotating.
• When the robot rotated, it seemed that one motor simply stopped driving momentarily. It was observed that this was consitently the same motor failing.

• The testing concluded by observing what the rotation was when the stepper motor drivers were swapped. The robot rotated the opposite way and it was deemed that one of the stepper motor drivers was not behaving as desired. The next step will be to replace both drivers with new, higher quality units and hopefully this will solve the rotating problem.

Please see a selection of the testing videos using this link, notably showing the robot rotating then failing.