Turning Quality Metrics
 

On CD we talk about drivetrains a lot. Straight line metrics are pretty common in these discussions: top speed, acceleration time to top speed, max pushing force, time to distance, etc. But what about describing turning?

I have thought about how to quantify turn quality on and off for several years and never came to any conclusions on my own. The discussion in the thread on CoF testing has me thinking I need to turn it over to the larger community.

The crux of the thinking is what metrics can be used to define chassis A turns 'better' than chassis B. I have heard comments over the years of software improving drivability, but I am not sure what that means. Ideally identifying the correct metrics and the sweet spots for them could become design targets. Even if these targets are driver specific.

Things that I have thought about over the years include, but are not limited too:
What is the current required to maintain a given turn rate?
Where is the center of rotation of the robot?
How much 'stutter' is in the turn? (Irregularity in the turn rate over 360 degrees of turn at some constant target rate.)

So I ask the community to brainstorm, what is important in characterizing how a robot turns? Feel free to suggest things even if you don't know how to measure them as someone else may jump off your idea or fill in the blank.

Re: Turning Quality Metrics
 

Re: Turning Quality Metrics
 

I think an interesting test would be taking a mesurement of how much the drivetrain "rocks" during a turn. One way to meadure this would be putting a mast on one end the robot, a vertical stick that was 5 feet tall and recording the position of the top of the stick. Any vertical displacement would indicate that perhaps the drivetrain was rocking. For me, a drivetrain with no rocking is desirable.

Re: Turning Quality Metrics
 

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.

Re: Turning Quality Metrics
 

Is that a function of the software more than the mechanical system? To me it is counter-intuitive to think of this as a virtue for the mechanical system.

I can make a mechanical system with so much turning scrub that it will never overshoot... but by definition that kind of hurts my turning torque.

Am I missing something Chris?

-John

PS - For those that don't know, Chris is (imho) the "turning master" -- he wrote one of the best whitepapers in the history of Chief Delphi, back when most people were building 2WD or 4WD robots, and many of those teams who did 4WD couldn't get them to turn worth a dang.

Re: Turning Quality Metrics
 

Think of handling qualities as a marriage -- often a very rocky one, but where divorce is not an option.

Looking forward to the discussion on this one. :)

Re: Turning Quality Metrics
 

When observing robots turning, I look first to see if the robot "jumps" or "hops" in the turn. This to me is a good indication that the tires need to break friction with the floor in order to turn. From an electrical standpoint, that operation puts the drive motors at nearly full stall current. For four CIM drivetrains that is over 400 amps. In multiwheel drives, this is a definite problem if the wheels are not set at different heights and are adjustable for tread wear. A good multiwheel design effectively reduces the wheelbase (and subsequent currents) without compromising stability. In crab designs, it will be hard to tell if the team has made any compensation for turning in the driving software without asking the people who would know. Typical crab designs, will experience the same turning frictions as other four wheels designs unless there is some speed modification made to allow one side of the robot to drive faster than the other. What makes the crab design more complex is the normal side forces encountered by the crab modules during the turns are transferred to the bearing surfaces at the top of the module. If there is no design plan for these forces, not only do drivetrain currents skyrocket, but steering motor currents also rise. As such, most crab designs will not be able to have tight turning radii without excessive currents encountered in standard four wheel designs. Robot designs that use a descending mechanism, foot or omni wheel, will be capable of tight turning (zero point turns) and low current. Excessive currents lead to power supply problems known to affect Crio, Radio and camera.

Re: Turning Quality Metrics
 

Yes - but that's not your fault. I was a little vague, probably because I was distracted while writing that post. My point was that there is an optimal amount of scrub (not just less scrub is better).

From a mechanical standpoint, the overshoot is a function of moment of intertia, top turning speed, and friction. You can make a drivetrain with a large moment of inertia, 2 rough top wheels on one end, and two casters on the other. Good luck driving that (my team made one of those a LONG time ago and decided that it was almost undrivable). Our 2010 robot with 2 omni wheels on one end was on the border of being difficult to drive without software help.

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

If you can make a nice, smooth turning robot without omnis or casters, it's a much easier drive system to control. Changing to omnis will make your robot VERY easy to turn, sometimes too easy. I find that the robots are easiest to drive with enough mechanical damping to keep overshoot less than 10 degrees or so.

Re: Turning Quality Metrics
 

By the way, I came to the above realization (optimal scrub) in 1998. Our first two years had decent drive bases, but nothing great. We started with a system that would barely turn, so we did what seemed natural: side scrub = evil: let's add casters! The casters were nearly a disaster as the nose would swing wildly as we tried to drive it.

We went to our first regional and saw team 1 (the Juggernauts), which is still one of my favorite robots of all time. They had a perfect 4-wheel drive system with just the right amount of scrub, and their robot was SUPER easy to drive.

That got me thinking about how to set out to design a drive system with the "right" amount of scrub from the beginning. That led me to do a lot of scribbling in my notebook - those scribbles later become organized into the paper.

Re: Turning Quality Metrics
 

I concur with Chris on there must be an "optimal" amount of scrub.

We seem to start the season with too much grip and work our way towards better manueverability as the season continues. Some is software, some if practice with the driver, but often it is wheel selection adjustments to improve manueverability.

In 2008, I did a spreadhseet tool that calcuatled turning power through various corners at various speeds. We tried a lot of wheel configuration that year and ended up with an asymmetric mix due to the circle track "only turn left" style of driving. I want to say that our most "loose" chassis only required 50W differential to start steering. Our heaviest scrub "for that year" was around 300W (this would ahve been a good configuration in most other games). Our final configuration required about a 150W difference. This allowed the driver to keep the outside on full and just release the inside to initiate the turn. With the 300W configuration, the driver actually had to reverse the inside ever so slighttly to get the robot to turn which slowed it down immensely.

You could probably create a software test for "goodness" by using a gyro and inducing a full power spin for 720 or 1080 degrees, and then removing power. Speed to complete the turns, and amount of overshoot after turns are completed would likely correlate with some overall driveability goodness.

Re: Turning Quality Metrics
 

The Nonadrive was a mechanical system that had features that could be used to reduce/eliminate turning overshoot (ex. timely deployment of the traction wheels).

Re: Turning Quality Metrics
 

I've always heard 4wd bases with two opposite corners using traction wheels and two using omni wheels steer well without overshooting. The problem is that more times than not the onmi wheels are slightly undersized, which causes rocking and the traction loss of one traction wheel at any given moment (on a flat surface).

Another workaround for omni drives that fishtail or overshoot is to tighten up the rollers... the challenge there is finding the sweet spot where the rollers turn with the right amount of resistance.

Re: Turning Quality Metrics
 

Another nugget to consider when identifying "optimal scrub." As pointed out, having mechanical resistance to turning is not a bad thing when it comes to overshoot, but it goes beyond that. A large portion of "pushing matches" in FRC, especially among smarter teams, aren't head-on battles. They are usually one team attempting to spin another team. More scrub would mean more mechanical resistance towards other team attempting to spin your robot.

Re: Turning Quality Metrics
 

An easy characteristic to measure that could be considered a turning metric is the "drive symmetry" of the drivetrain. It comes down to the relationship between turning to the right and turning to the left.

Under most circumstances, you want a set differential force to turn the robot at a certain rate, regardless of the direction of the turn. An easy way to test this on a robot is to spin in place at full power, first clockwise, then counter clockwise.

The reason why this is important is that a more "symmetrical drive" will require less trimming to drive straight, giving the driver more power to play around with.

Re: Turning Quality Metrics
 

Though it makes me nervous to dissent from my much more experienced colleagues...
I disagree on a purely qualitative basis. In 2011 the Robowranglers built a Nonadrive (4 traction + 5 omni) as Raptor's drivetrain. During initial "live fire" tests, we hypothesized that the side-side wheel wasn't actually much of an advantage. We pulled the circuit breaker from the middle wheel, and zip-tied it up -- performance actually increased. (Note: I still believe the side-side motion is useful in some games, just not 2011).

Our plan was to then swap out the omni-wheels for some medium-traction wheels like kit wheels or Colsons to get the performance as described by others in this thread. What happened next was surprising...

We found that in the 4-omni wheel skid-steer configuration (which we've dubbed "butterfly drive) our driver was able to execute some incredibly smooth, and quite precise maneuvers. He was able to also do some "slide" maneuvers we hadn't anticipated.

I would have never speculated that a "zero-scrub" drive would perform like it did, but with Connor on the sticks the thing performed great, and provide benefits that would not have been present in another system.

That said...

Agreed. "Zero" Scrub to "Infinite" Scrub with the push of a button.
Perhaps Connor's ability to "drop traction - lock heading" helped him avoid over-shoot issues.

My thinking is...
Mechanically balancing scrub to prevent overshoot will help with driver smoothness, but are sacrifices being made to achieve this? What do you give up to help your driver deal with overshoot?

Good discussion. :)

-John

Re: Turning Quality Metrics
 

I totally agree with your nonadrive experience, but there should probably be a giant * which you eluded to about talented and/or experienced driver.

Less experienced drivers tend to do better with more scrub. that is part of the reason our robots have more scrub at teh start of teh season than the end of the season.

You can set up a front drive car to have slight over steer (likely to spin), and a a driver with reasonable car control on a racetrack will be way faster than one that understeers. That being said, there is a reason why even street performance cars have understeer.

Switchables though get a category of their own. I really enjoyed our 2011 chassis, and I am a huge fan of the 469 style caster drives.

PS, I would love to have watched a talent show between the 217 and 148 drivers in 2010. I got the opportunity to watch a 217 practice, and the speed an maneuverability was absolutely amazing.

Re: Turning Quality Metrics
 

Do you have a video link showing the awesomeness?

Re: Turning Quality Metrics
 

Awesomeness is subjective. We like it.
Any match video from 2011 would somewhat show it. In the teaser video you can see some of the drift moves, and you can see Connor kind of whip the robot around a few times (he backs into the rack, then spins the front around to score).

I had to google it... :p

Re: Turning Quality Metrics
 

IKE, I'll be curious to see how what you say unfolds... my goal is to make *any* driver look good by making the controls very intruitive for anyone to drive. I'd argue less experienced drivers need any intuitive help they can (e.g. just as Jake has mentioned with the field centric drive for team 1717), and should be able to drive any kind of well defined drive with a virtually identical feel to them.

I cannot completely back up this arguement... just yet, > ; )
but I believe this enough to take a leap of faith and do it.

Oh yes... do you want to share how driving with PID closed loop encoders help with turning performance and latency?

Re: Turning Quality Metrics
 

James,
This activity seems like it would be very "high effort, low reward" compared to other developments an FRC team could be doing.

I'm going to assume you're going to do some driver drills... if your team isn't the type of team that does driver drills, you're probably not capable of doing what you're describing anyways.

Training drivers isn't that hard. If you're going to run some driver drills you're going to quickly move past the part of the learning curve where this software would matter anyways.

Maybe I'm under-estimating the reward, and over-estimating the effort required for meaningful result.

-John

Re: Turning Quality Metrics
 

I remember a saying that goes something like

Good robots with bad drivers can lose.
Bad robots with good drivers can win.
Good robots with good drivers can dominate.

That being said, we usually get software to around 80-90% then let the drivers learn to drive the thing. The last 20% takes 80% of the time. (Pareto principle)

Re: Turning Quality Metrics
 

One that our mentor likes is "a 100% robot with 50% drivers is a 50% robot."

Re: Turning Quality Metrics
 

It was high effort, but now it is a well-defined solution... so it's really an inherited benefit... with no time invested here... but my time invested now is in learning about interfacing with the basics robotics drive itself... gears torque etc... stuff I need to learn no matter what solution we choose. I have gone over your spreadsheet with a fine tooth comb and use this as a simulation. (More on that in the other post on cof tomorrow).

We do driver drills... I listen to the driver's needs and I've talked with Jim Z as I'm very inspired by Team 33's method of drive control. I am not afraid of new innovation. We have to continuously challenge old paradigms and believe and continue to try new things.

For me the reward is that great feeling I saw when we continued to successfully balance the ramp for Rebound Rumble... to make the driver feel like he is at one with how the robot performs. I remember the moment I hesitated when I crashed my car because it was not intuitive to me (I did not know how to quickly react to slow down a standard stick drive). The reward is for a user to not need to worry about what to do when he panics because it is intuitive.

Re: Turning Quality Metrics
 

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

Re: Turning Quality Metrics
 

John,

I've reviewed the 4WD paper these past few days. It seems to me that 4WD is not as forgiving on center of mass as 6WD. That is a great paper... I'm tempted to take the starting equations into a dynamic direction for actual simulation.

Re: Turning Quality Metrics
 

Yes. 6WD is just two 4WD robots in one. The "rock" of the 6WD alternates between the two different 4WDs, which each have a very short length wheel-base. You get the benefits of a short-length wheel-base without the tradeoffs on stability (if the robot starts to tip, the other wheels are there to catch it).

Once you plug the equivalent 4WD config (from a 6WD robot) into Chris' equations, you can see why it is great at turning. Especially because in this case, the CoM is usually close to being between two of the 4 wheels in contact (the middle 2 of the 6WD).

Physics still works. :)

-John

Re: Turning Quality Metrics
 

I never thought of it like that... all this time I thought the turning was only happening on the 2 middle wheels... I guess that only happens on a rare moment when the drive is balanced.

Thanks... now I've applied this bug fix in the code. ;)

Re: Turning Quality Metrics
 

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?

Re: Turning Quality Metrics
 

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.

Re: Turning Quality Metrics
 

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?

Re: Turning Quality Metrics
 

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

Re: Turning Quality Metrics
 

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.

Re: Turning Quality Metrics
 

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.

Re: Turning Quality Metrics
 

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?