Turning Quality Metrics

[Sparks333]

In terms of practically any system with which you are attempting precision outputs, I'm biased in the direction of classical controls metrics - rise time, overshoot, 2% settling period, steady-state error, that sort of thing. If you consider the command to rotate to some large angle as a sudden input to a system in equilibrium, you can use these metrics to figure out how well your control system is tuned to your robot - the classic example is using this information to tune a PID, but even observing the robot's behavior without a closed-loop control system can tell you about how quickly the robot is capable of changing its state, and how stable it will be when you get there.

I fully agree with JamesTerm in that all characteristics (with the possible exception of rocking) can be drastically improved with the addition of control software. Even with a great driver at the sticks, the driver isn't really driving the robot - he's driving a model of the robot in his head. The closer the actual robot follows the model in his head, the better he will be able to make predictive corrections. Therefore, it is software's job to try and make the robot behave as much like an ideal model as possible (then stop fiddling with it and let the driver figure out quirks on his own).

One point that JamesTerm didn't bring up but I feel is important is that in order to really get great control and performance from your software, it's highly advantageous to use sensors on your robot - encoders are the classic, but gyros and accelerometers can work too, if processed correctly. The handling characteristics of your robot will change drastically at different speeds and during different maneuvers, so having a sensor suite that can compensate will work much better than attempting open-loop control.

/tangent

Sparks333