paper: Battery Voltage in Robot Drivetrain Simulation and Modeling

[Al Skierkiewicz]

Originally Posted by apalrd

Al, at 400a, what are the losses of a #6 vs #4 battery cable? We always keep the length short (never adding length to the 12" COTS cable and using a ~6" wire between Main Breaker and PD), and wondered if switching to #4 on one or both ends would help.

Assuming that you are talking 12" on both sides of the Anderson connector, the resistance of #6 would be roughly 0.002 ohms. Moving to #4 would cut that in half. So all things being equal, moving to #4, 400 amps would give you another 0.4 volt available at the PD terminals. We choose to trade off the free weight of 12" of battery cable for the slightly higher loss. Then try to keep all wiring short to minimize losses and balance the loads.
I can't tell you how many teams over the years have come to me trying to make their autonomous run straight. By far most of these teams had several more feet in the wiring feeding one side of the robot then the other side. To all teams, your robot design should try to keep the PD centered in the robot base so that wire runs to drive hardware is short and similar lengths. All other loads are secondary to the drive. The cRio doesn't care where it is located, neither does the DSC, compressor or other loads. When a team asks if I can determine a problem with their drive, one of the questions will be "how fast did you design your robot to move and does it move as fast you expected?" When the answer is "no, it doesn't go as fast as we expected" then I look for where the PD is mounted and the length of the wiring to the speed controllers and motors. While mounting to make things pretty is great, it is not always the best choice for electrical losses.

[DampRobot]

First of all, what a great resource for the CD community! I'm very thankful for the thoughtful research that went into to this paper, and that you released this for everyone to benefit from.

I have a few (scratch that, lots of) questions about your methods and findings.

First, given a desired sprint distance (ie, a distance which high gear is optimized for), how does this translate into an actual distance that we can plug into your calculator? Usually, we want a robot to be stopped, or close to stopped at the end of our sprint distance. If we want to go from stopped to, let's say 15 feet, you don't realistically accelerate for all of that distance, so it would be inappropriate to design for the highest speed possible at 15 ft, or lowest time to 15 feet. On the other hand, an FRC robot does not need equal times to accelerate and decelerate (like a spaceship would), so it would be wrong to design around a time to 7.5ft or max speed at 7.5ft. Would you just go with a "medium-ish" guess of acceleration for 12 feet and deceleration for 3 feet? Is there some more analytic way to determine the "max speed distance" given the desired sprint distance?

Second, which do you more design around, time to distance, or time to speed? You mentioned that you wanted time to speed as well as time to distance, so you didn't end up with a ratio that accelerated too slowly. Does this mean that first find the best gear ratio for time to (sprint) distance, and then check the time to speed to see if it looks OK? Or do you work to optimize time to speed as well as time to distance?

My third question has to do with your battery voltage calculation method. Could you solve for battery voltage with a differential equation, given motor speed and load? Or is your iterative method of calculation a better simulation of the real world? Ie, does current drawn in one microsecond determine battery voltage in the next microsecond (which determines current drawn, and around the cycle goes), or is this just a situation where a calculus approach is just overkill?

[apalrd]

First, the design distance ('Ref Distance' on the calculator) is used as the time it takes to accelerate to that distance from stopped. I don't include decel time, just accel time. You would still be moving when you reached that distance. I did not write the majority of the calculator, it's JVN's.

Second, Time to Distance. Time to Speed is used to validate acceleration targets, to make sure shorter-distance movements might possibly be acceptable.

Third, this method was the easiest method to implement. It has some noise, especially at the start, so I filter the voltage. It seemed to work well enough.

The reason I calculate it iteratively is because voltage is needed to calculate torque in the mechanical portion of the calculator. So, I calculate voltage from the last iteration current, for use to calculate this iteration's torque. The voltage change per iteration is so small that I don't really need immediate accuracy.

[JesseK]

Thanks for sharing Andrew. It's something I've never considered in my spreadsheets since it was an unknown assumption. I took my lunch hour and did algebra to come up with a solution for x(t) because the "Battery Voltage Gain Filter" strikes me as wonkish (though that filter is an interesting way to fix the problem). The result was based on some constants that are pre-computed via the motor & robot properties, yet the point is that (luckily) a solution exists for the non-linear differential equation:

Results on Wolfram|Alpha

It's not exactly pretty, and solving that solution for t (so time can be a function of gear ratio) is causing WolframAlpha to blow up... so more work will have to be done. Yet it does allow for more straightforward calculations of pretty much everything (including voltage) without the need for circularly-dependent equations that need several hundred lines at high resolution to get accurate.

Pretty equations for constants A, B, C, D & E to come tonight or early tomorrow.