It's alive

Today I managed to get things going with the compilation and had the robot running around the lab with existing code. Also did some modifications to the code base in order to use FPS style controls.

What's a bit strange is that this robot actually has worse straight line driving than our thesis bot at the moment. So I'm preparing to perform several upgrades to the robot base driving code in order to match the thesis bot driving as it should preform better since every component is much more accurate and faster on this robot.

One thing that stands out is that MvM choose to use a full PID controller where in our thesis project we eventually dropped the PID in favor of just plain PI due to the negative effect of the D component.

At startup currently the robot violently oscillates before it's able to find some sort of steady state, I'm pretty sure this is because he doesn't bother removing the D component on first run this would cause the robot to cacluate d(off center) / dt where dt = 0, whick would create a violent oscillation as we briefly get infinity.

To confirm the problem I'll be turning off the D component and checking the behaviour of the system. If I get more stable behaviour I'll try and fake dt for the initial run giving it some effectively high value such as 100 to minimize the effect of the D component when calculated at the beginning. This should be easier and preform better than some branching code where we don't use dt at the initial run.

Our thesis bot was smart enough to self calibrate, this was done by running the motors for a set distance until steady state was reached in our PI controller. The accumulator for the I component was then exported to the system for later use thus when the robot is run the next time it would start closer to steady state. This is because we know that if motor A is less powerful than motor B it's quite likely that that doesn't change between runs in that motor A will always be more powerful than motor B by close to the same amount. If we see that last time we needed to send less power to the motor A and more the B in order for them to match speed and we record what this power difference is, than we could use it again and chances are we get pretty close to perfect movement again.

There was a more advanced version of self calibration to implement on our thesis bot but eventually gave up because the bot was too limiting. Even though we know the robot motors were off by certain power levels the recorded values are for the system when it's "at speed". While the robot is accelerating these power levels might not be accurate. A more advanced system I might try is to take readings at different speeds and derive a linear or polynomial approximation for the power curve required to seed the system while it ramps up, the disadvantage here is the system will be "floating" as each interpolating point will change during the run as each new power level is achieved. Unfortunately the only way to determine the ramp up power difference is to run tests and premodel the system rather than dynamically build a model inside the system itself.

Essentially what we are trying to do with advanced calibration is to scale Ki component of the PID controller proportional to the system speed so that Ki is small when the system is running slow and Ki is large when the system is running at higher speeds, or in other words Ki will try and effect the system proportional to the speed it's at. I have a theory this might be pointless but I'll need to model it to find out if that's so, as I builds fast when the wheels are spinning fast and I builds up slow when the wheels are spinning slow anyways. This side effect might end up being the same as if I scaled Ki.

The final method is to take our advanced telemetry engine (which was also unimplementable) where we calculate the error based on error = dy/dt where dy/dt represents the deviation from center. This is a strange approach but we actually work with physical distances rather than ticks, I'm still unsure how different this will be from our original ticks model since essentially in the ticks model I do close to the same thing except I measure if one wheel spun more than the other. Not how far I'm from the centreline this last method will be implemented ifjavascript:void(0)
Publish Post I can prove that it'll provide substantially better results than the current method.

Ok that's enough thoughts for today.