Turning Quality Metrics

[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

During the discussion 'scrub' was central to many of the comments. I can see ways that 'scrub' is integral to most of the items on the list, but is there one of these that is more directly tied to pure scrub? Does defining pure scrub even matter?

Also, IKE mentioned that he calculated the power differential required to initiate a turn, and the peak turning torque can be calculated using the method defined in Hibner's white paper. Is it safe to presume that the others are direct measurement of a completed machine? If so are there practical ways to measure them and are there practical ways to validate the analytical methods?

[Gdeaver]

This is a good thread after this year. I was surprised by the shear number of teams this year who had the " my robot can't turn" problem. Yes many teams did have agile robots but so many did not. The need for traction on the bridge and design efforts to cross the barrier probably led to the problem. A large portion of First teams have gone with a type of conveyor belting on IFI, Andymark, or a custom wheel with a flat tread profile. There have been many discussions of COF for the different tread and wheel versions. To really take on the turning dynamics problem, I submit that teams will have to go beyond measures of flat surface static and dynamic models. The playing field surface is carpet and and robots sink into the carpet. This adds another dimension to the model. Also, note that the carpet that we play on has a grain which affect how a wheel turns in relation to the grain. I believe teams need to not only look at the COF testing but need to look at how different wheel profiles affect turning. Remember the old Skyway wheels that used to be in the kit? They had a V profile. Has any team taken the time to try V or rounded profiles to see the affect on turning? We did in the fall of 2010 and I submit that a flat tread is not optimal. Think about it.

[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.