Turning Quality Metrics

[JVN]

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.

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.

[Ian Curtis]

Originally Posted by JVN

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.

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.

[Al Skierkiewicz]

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.

[Chris Hibner]

Originally Posted by JVN

Is that a function of the software more than the mechanical system?

Am I missing something Chris?

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.

[Chris Hibner]

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.

[IKE]

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.

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

[Jared Russell]

Originally Posted by JVN

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.

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

[ratdude747]

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.

[Lil' Lavery]

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.

[Garrett.d.w]

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.

[JVN]

Originally Posted by IKE

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

<SNIP>

Originally Posted by Chris Hibner

My point was that there is an optimal amount of scrub (not just less scrub is better).

<SNIP>

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

Originally Posted by Jared341

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

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

[IKE]

Originally Posted by JVN

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

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.

[JamesTerm]

Originally Posted by IKE

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 the start of the season than the end of the season.

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?