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

[JamesTerm]

Originally Posted by kramarczyk

In reviewing this thread I see the discussion boiling down to seven metrics.[*]Overshoot (angular)[/list]

I found another solution to help address overshoot as even with a well-tuned robot this can still be an issue. I found this out yestday on my simulation http://youtu.be/MRPuvRUOB28 . Where if you have wheels that have lower CoF, it warrents the need for a slower acceleration and deceleration rate to avoid slipping. Even when getting this rate optimal I found the model not doing what I wanted it to do (over shoot), and I really got frustrated, so I remember coming across this some time ago:
http://www.chiefdelphi.com/media/papers/2421

And so I tried the X' = a1*X^3 + (1-a1)*X ... equation, and sure enough this made all the difference in the world. Thanks Ether.

[JamesTerm]

Originally Posted by Chris Hibner

Yes, it can be taken care of in software, but all of those reverse motor commands create a lot of heat and a lot of stress on a lot of parts. We've done software driving aids whenever needed, but I prefer to have a good mechanical pacakge that doesn't require any help (don't we all).

I'd argue that if done properly (e.g. trapezoidal motion profiling) the additional amount of heat and stress can be minimal and insignificant. It's possible to even curve the trapezoid legs to ensure the chain slack when changing directions is controlled while still maintaining a reasonable ramp time.

[Mr. Lim]

I'll propose a turnability metric:

Angular Speed / Linear Speed

where:

Angular Speed is the max degrees/sec in an on-axis, in-place spin.
Linear Speed is the top speed in feet/sec in a straight line.

Both measured on standard FRC carpet, of course.

I'd be interested in hearing from some experienced multi-speed gearbox teams about a metric like this. Lower gears would likely produce a better turnability score than a higher gear, but I've had drivers who simply "like how the robot turns" in high gear much better. Have you seen this as well?

This leads me to believe there is such thing as a robot that "turns just right," which is supported by the discussion here regarding having too much overshoot.

It'd be neat to quantify what the "perfect turnability" is for different FRC tasks - traversing the field to get game pieces in 2011 vs spinning on axis to line up a shooter in 2012. Are they different enough to justify having two gears?