Turning Quality Metrics

[JamesTerm]

Originally Posted by kramarczyk

In reviewing this thread I see the discussion boiling down to seven metrics.

1. Peak Turning Torque
2. Speed of Turn (given angle)
3. Rock During Turn
4. Overshoot (angular)
5. Hopping During Turn (smoothness)
6. Power Differential Required to Initiate Turn
7. Drive Symmetry

In regards to Peak Turning Torque, speed of turn, overshoot, and power differential required to initiate turn... I believe all of these can be improved with software assistance.

How is this possible? With software aid... it can measure the users intentions and gets to any desired angular velocity as quickly as possible by applying the correct amount of voltage at each iteration to overcome the inital grip and mass, and on deceleration applies the optimal reverse voltage to fight against the moment of inertia which in-turn mitigates overshooting issues.


Now I finally get what JVN has been trying to tell me in regards to a good trained driver on a good robot with no software aid. I think of the analogy of a drag race between two cars, one manual transmission and one automatic. The driver of the manual has more control and can get the ideal RPM before shifting gears, while the other driver has less control and his faith relies on the automatic transmission, and yes the guy in the manual transmission wins the race cause he's opimized getting the most control from the gearing.

Using this same analogy I'd be interested in the following statistic: There have been many racing arcade driving games that allow the player to choose manual or automatic. If we could survey the percentage of people that choose automatic over manual... I'm willing to bet it would be significant for automatic. I think times have changed where intuitive controls are favorable to the manual ability to "feel the car" as the player can focus on more important things like staying on the road dodging cars etc.

In regards to software aid, computers are faster than humans and can really "feel the car" doing most the grunt work making it more intuitive for the human. This isn't a substitute for a good mechanical machine, but I see it this way... you have two robots that need to turn exactly 180 degrees as quick as possible. one is mechanically sound with good wheel placement, CoM, tread profile etc. The other robot not quite on par with these things, but is on the bottom end of being a good robot. The manual driver has to apply a bit more initial force to get the turn started and then has to apply reverse voltage to get it to slow down and avoid the overshoot, while the other driver works with a perfectly tuned acceleration curve (to his liking) feel on the joystick... moves joystick out choosing his desired velocity from a good x^2 curve distribution and see's the robot matches in response to what felt right and when it gets closer to its mark he brings joystick back in and then releases the joystick... See how this puts a new spin on the 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

I'm a big believer in overshoot as a turn quality metric (as in, less is better). It's great that a chassis turns nice and easy, but it's not great when it continues turning for an extra 30 degrees after you let go of the stick.

I believe this issue could be fixed in software as one programmer once told me (In regards to closed loop PID) "All this math produces motor speeds necessary to get the true desired motor performance not necessarily what the user actually told the arm motor to do. (it is smarter than the driver )."

I've measured around a 200-300 ms latency from when a voltage applied to when it actually takes effect. I realize now that this is due to moment of inertia on all the gears and wheels as well as CoF.

Perhaps this side-by-side graph can paint a picture of what I mean:
http://www.termstech.com/files/RateG...on_400_100.gif