

Students dream up the ideas for bots, it is than up to the mentors and engineers to make these dreams a reality.  dddriveman [more] 



A series of tests performed on a standard drivetrain, showing how to characterize a drive's behavior in terms of voltage, velocity, and acceleration.
Me and Eli (Oblarg) have been working this preseason on a project that started as just trying to see how linear the frictional forces in a drivetrain are, but quickly grew into coming up with a pair of equations that show how an FRC drivetrain behaves for a given voltage. It's pretty easy to find these equations, and it'll give you a good degree of precision on how your drive will behave, without needing any encoders. We got 2% accuracy in openloop motion profiling for a wide variety of profiles, and .2% for closedloop. The data we used are linked at the bottom of the white paper, and all the graphs were generated in R using ggplot.
motor_characterization.pdf
download file11152017 03:02 PM
OblargSomething I didn't get around to cleaning up for inclusion in the whitepaper, but which is kinda cool regardless: Here's a 3d scatterplot with bestfit plane of motor voltage over the whole velocityacceleration plane:
Edit: Note that the intercept of the plot is nonzero, as the voltage axis does not start at zero. This is, as mentioned in the paper, very important!
11152017 07:17 PM
GeeTwoI'm pretty sure I followed everything here, and see how we can use this to significantly improve programming the robot, both in openloop and feedforwardclosedloop scenarios; I had been worried about not including static (as opposed to viscous/speed dependent) friction in the control software for a while. +reps to you both!
Were you able to learn anything that would help in designing the drive train?
Edit: You must spread some rep around before giving it to noah.gleason again.
11152017 07:23 PM
Oblarg
Were you able to learn anything that would help in designing the drive train?

11152017 10:06 PM
ChakGood read, I learned a couple things here today.
To check my understanding, is it correct to say that the .8 multiplicative fudge factor is only accurate at or near the top speed of the robots that were tested to get that .8 fudge factor? So that the .8 factor would work for one "usual" FRC speed, and get more inaccurate as the top speed deviates?
I wonder if it would lead to more intuitive controls if the joystick was scaled to velocity instead of voltage.
Can this be applied to increase acceleration by keeping the wheel on the edge of slipping? By measuring the torque/voltage at a steady state wheel slip (robot pushing against wall or something), and then measuring velocity as the robot speeds up, can't equation 14 be applied so that the robot operates at the edge of wheel almost slipping? Or maybe even make sure the robot always operates at the edge of wheels almost slipping no matter what, to decrease tire wear. How significant would that be? (I have no idea whether wheels slipping is an issue or not, so idk)
11152017 10:50 PM
Oblarg
To check my understanding, is it correct to say that the .8 multiplicative fudge factor is only accurate at or near the top speed of the robots that were tested to get that .8 fudge factor? So that the .8 factor would work for one "usual" FRC speed, and get more inaccurate as the top speed deviates?

I wonder if it would lead to more intuitive controls if the joystick was scaled to velocity instead of voltage. 
Can this be applied to increase acceleration by keeping the wheel on the edge of slipping? By measuring the torque/voltage at a steady state wheel slip (robot pushing against wall or something), and then measuring velocity as the robot speeds up, can't equation 14 be applied so that the robot operates at the edge of wheel almost slipping? Or maybe even make sure the robot always operates at the edge of wheels almost slipping no matter what, to decrease tire wear. How significant would that be? (I have no idea whether wheels slipping is an issue or not, so idk) 
11152017 11:40 PM
ChakThanks.
You should try this and report back on how well it works! 
11162017 12:17 AM
Oblarg
lol, I don't have a team right now. Would someone else care to try this?

11192017 12:58 AM
AustinSchuhThis is awesome! Thanks for doing the research and posting your results!
11192017 09:39 AM
Ether
To check my understanding, is it correct to say that the .8 multiplicative fudge factor is only accurate at or near the top speed of the robots that were tested to get that .8 fudge factor? So that the .8 factor would work for one "usual" FRC speed, and get more inaccurate as the top speed deviates?

11192017 03:49 PM
JesseKIf you add more friction to your robot and rerun the Quasistatic kV determination, does the value of kV change? For example, say you introduced a small rubber pad that rested on top of all 6 wheels, do you reach the same kV value as without them?
11192017 05:51 PM
Oblarg
If you add more friction to your robot and rerun the Quasistatic kV determination, does the value of kV change? For example, say you introduced a small rubber pad that rested on top of all 6 wheels, do you reach the same kV value as without them?

11192017 08:47 PM
JesseKInteresting. Knowing which constant to tune late in a season (as robot parts wear) is crucial to keeping consistency in automation. I think this paper lays a good foundation in that regard. I'm still digesting it though; some of the explanations are a bit of a leap without references.
04142018 07:07 PM
virtualdHas anyone explored potential ways for computing a theoretical value of Vintercept?
04142018 07:40 PM
GeeTwo
Has anyone explored potential ways for computing a theoretical value of Vintercept?

04142018 07:41 PM
virtuald
A theoretical computation would require a lot of buildspecific inputs about mechanical friction. However, it's not too difficult to measure. Just drive the robot slowly, keeping it moving without grinding to a halt. Meanwhile, log the product of Vbat and the duty cycle.

04142018 07:58 PM
GeeTwo
I'm thinking about this more from a simulation point of view  it would be nice to compute a theoretical value for a robot that doesn't exist yet, or a robot that is in a bag or is otherwise inaccessible. Not everyone has practice robots after all.

04142018 08:56 PM
virtualdWell, a SWAG is fine, but I was hoping someone had tried to estimate the relationship between vintercept and the various parameters (mass, static friction, voltage, etc... ) so it could be vaguely computable. Of course, I suppose that might not be possible.
04152018 05:39 AM
Oblarg
Well, a SWAG is fine, but I was hoping someone had tried to estimate the relationship between vintercept and the various parameters (mass, static friction, voltage, etc... ) so it could be vaguely computable. Of course, I suppose that might not be possible.

04222018 03:28 PM
virtualdI'm trying to duplicate the computations given in the paper, and I can't seem to get the same numbers for ka. Here's what I have:
CIM_NOMINAL_VOLTAGE = 12 # volts CIM_FREE = (5310 / 60) # rps CIM_STALL_TORQUE = 343.4 # oz/in CIM_STALL_AMPS = 133 # amp CIM_FREE_CURRENT = 2.7 # amp wheel_diameter = (3.8/12.0) gearing = 6.1 nmotors = 3 robot_mass = 110 max_velocity = (CIM_FREE * math.pi * wheel_diameter) / gearing max_acceleration = (2.0 * nmotors * CIM_STALL_TORQUE * gearing) / (wheel_diameter * robot_mass) kv = CIM_NOMINAL_VOLTAGE / max_velocity ka = CIM_NOMINAL_VOLTAGE / max_acceleration print('vmax=%.3f amax=%.3f kv=%.3f ka=%.3f' % (max_velocity, max_acceleration, kv, ka))
04222018 09:49 PM
Oblarg
I'm trying to duplicate the computations given in the paper, and I can't seem to get the same numbers for ka. Here's what I have:
Code:
CIM_NOMINAL_VOLTAGE = 12 # volts CIM_FREE = (5310 / 60) # rps CIM_STALL_TORQUE = 343.4 # oz/in CIM_STALL_AMPS = 133 # amp CIM_FREE_CURRENT = 2.7 # amp wheel_diameter = (3.8/12.0) gearing = 6.1 nmotors = 3 robot_mass = 110 max_velocity = (CIM_FREE * math.pi * wheel_diameter) / gearing max_acceleration = (2.0 * nmotors * CIM_STALL_TORQUE * gearing) / (wheel_diameter * robot_mass) kv = CIM_NOMINAL_VOLTAGE / max_velocity ka = CIM_NOMINAL_VOLTAGE / max_acceleration print('vmax=%.3f amax=%.3f kv=%.3f ka=%.3f' % (max_velocity, max_acceleration, kv, ka)) I assume I'm not using the right units for CIM_STALL_TORQUE, but I've tried a bunch of different units and none of them have worked out. I had expected the unit to be in ft/lb ... but that yields amax=1.867 ka=6.427 which seems really off. 
04232018 11:08 AM
virtuald
Edit: I was too quick to assume that the mistake here was the common unit confusion, please ignore the first version of my post which has now been removed.
You've made some mistake calculating amax; here is the correct calculation. At a glance, it appears you have used the wrong value for nmotors (3 rather than 6; we are doing the calculation for the whole robot, not half of it, or else we would have to halve the mass), and also that you have used inconsistent distance units (your torque is stated in ozinches, but your wheel diameter is in feet). This is one reason I almost always use wolframalpha for calculations involving units these days; the unit handling is a godsend. 
04232018 12:25 PM
Oblarg
Thanks, that was really useful! Shows why I got terrible grades in physics back in college.
... speaking of which, I played with it a bit and still can't get the numbers for Amax working without units. Clearly I'm missing something. I'll try to show my work.
I recall from something somewhere there's a difference in how metric units and imperial units work... but according to wolfram it seems like I'm working with the right dimensional units. For the life of me I can't figure out what magic conversion factor I'm missing to make this work. Thanks for your patience! 
04232018 12:37 PM
virtuald
Ah, now you've run into the problem I addressed in my first (nowdeleted) version of my post  your unitless equation is correct, but your calculated acceleration is in units of gs, not ft/s^2. This is because you've used lbf for your force, and lbm for your mass; their ratio is the acceleration of gravity.
You've gotta be careful about this when using imperial units; if you don't want this to happen, you have to use slugs rather than lbm for your units of mass. 
04232018 12:53 PM
GeeTwo04232018 01:03 PM
virtuald
lb is pounds, a unit of force [weight]. The unit of mass in standard/imperial is the slug, which is the mass of something which weighs ~32 lb on the surface of the earth. An lbm (pound mass) is ~1/32 slug.
