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?