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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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?
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.
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).
John, you don’t want no scrub? Scrub from a chassis don’t get no love from you? Hanging out field side, watching Wrangler drive, explaining CoF to me.
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?
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.
