With the summers offering a lot of free time and the upcoming FIRA competition, the whole KRSSG team was literally beating the clock in order to get all the work done both in time and perfectly.
The link between the hardware and the software is the embedded system which takes in strategically decided moves from the code which determines the movement of the bot and translates it to the hardware which then follows the command. Using this example, one can well see how the embedded system kind of works as a translator.
For the FIRA competition, the circuits that were put on the bots were completely designed by the KRSSG team using the CAD software Eagle (PCB design software) - which was then fabricated in PCB Power. Further soldering was done manually by the team and that left the team with completely personalized and optimized circuits.
With the circuits ready, the team also implemented PID – Proportional, Integral and Derivative controller which is a generic loop controlled feedback mechanism which is used everywhere – even in industrial control systems.
Why do we need PID?
Because, life isn’t perfect. While theoretically we may calculate that to obtain a certain end result, we need to give a specific input – however, that input may not give the desired end result due to the real domain that we work in. A PID controller calculates an “error” value as the difference between a measured process variable and a desired setpoint. The controller attempts to minimize the error by adjusting the process control inputs.
Any PID controller needs feedback – we get our feedback from encoders from the Faulhaber motors which constantly tell the microcontroller about the rotation of the motor in real time.
The encoders on the motors that we use give 512 pulses in one rotation – Yes! They are so accurate that they can break one full rotation down into 512 segments and tell you exactly how much the motor has rotated. We then must scale this value down to our OCR (which is the register that controls the duty cycle of the motor input from the Atmega88PA micro-controller) target – and the maximum OCR that we can give is 255 (which corresponds to a 100% duty cycle) – which translates to a maximum speed of 9600 rpm on the motors.
Using some very intelligent calculations we arrived at the fact that if we count the total number of ticks – which can be counted by counting the number of pulses in the wave input from the encoders – for 3.2 ms, then this would be the perfect number. 3.2 ms is both a very small time fragment for the correction and also is a perfect scale down to 256.
So our work becomes a lot easier and our results become better. We set our target in the OCR as the desired number of ticks we want in 3.2 ms. PID ensures that the target is met. If you want 90 ticks, ideally OCR should be 90, but in a real system it is not – so PID gives you the correct value.
We get the target OCR value from the code which determines strategy. The embedded system then implements the PID and finds the actual/real OCR value that must be fed.
The most generic PID formula is:
OCR=OCR+ (KP*error) + (KI*integral of error) + (KD*difference between error)
Here, KP,KI and KD are constants which must be experimentally found out. We calculated the values using hit and trail with multiple runs of our FIRA bot.
We used the Ziegler Nicholls method to tune the three constants, along with some manual tweaking till we got the desired control output on the wheels. With the values of the constants we can now effectively and completely control the bot.
One step closer to the FIRA dream!