CIM Motor for Intense Direction Changes

It isn’t super effective, but it is better than a poke in the eye per Aren Hill’s testing.

I have to imagine there are techniques to modify a CIM for better cooling outside of FRC rules that haven’t been explored.

Also, cue discussion of 6x Mini CIM drivetrains from years past. Paul Copioli makes the case here, here, and here.

I would also take to heart some of the discussions about all-omniwheel drivetrains in Paul’s posts, assuming the court and your system can accommodate. The drastic reduction in scrub would cut down on current draw significantly as well.

1 Like

If I understand the intended use, I think it’ll just drive back and forth with no turning, so scrub shouldn’t be an issue either way.

Reading OP’s post back, it can certainly be interpreted as “I’m making a dead straight shot”. And if so, you’d be right.

yea Ik, the batteries are a massive pain. I am planning to use three 18 ah Batteries wired in parallel to achieve 54 ah. I’m thinking 54 ah will be enough to power around 6 Cims on base, 1 on linear puncher and 1 on a flywheel for at least half an hour, hopefully more. Considering that the machine won’t also be constantly running (will rest when time spent on picking up the tennis balls). Also pwm will conserve some of the energy as well.

Any thoughts, u think 54 ah will last?

They seem like a great option, just that the sparkmax motor controller for em is like 75 American…so might just stick to the CIMS and run them off a Talon.

1 Like

Are these new batteries, or used ones? I’d be leery of the latter situation, since mixing various ages of battery can result in the batteries trying to charge one another. If boot times are a concern for your system (you didn’t specify roboRIO or a HERO or something else), you could use one battery to power the control system itself and switch out the drive/launch motor battery as appropriate.

I would check my drive base setup against iLITE’s drivetrain simulator. Default reaction is to reach for Mini CIMs as they spin more efficiently (bearing in the output, less rotating mass, etc), but if those aren’t available to you for the same reasons a NEO isn’t you may discover you can reach your target sprint distance at an acceptable time with four (or for a super light robot, two) CIMs. That will cut down on current draw as well.

Regardless of motor choice, I would also pay attention to current draw through the PDP. If it’s going to run this hard for this long, a jump in current draw (or since we aren’t turning much, a significantly different current draw from left to right) is a sign that something has gone wrong or will soon.

Yeah, honestly while the NEOs are basically going to make most other FRC motors obsolete for competition use, you still can’t beat CIMs + a cheap motor controller for price. For an off-season project it usually makes more sense to go cheap.

On the note of cheap, some other things you might want to consider:

  • Do you actually NEED to use Talons for what you’re doing? Would a cheaper controller, like a Spark or a VictorSPX do the job, or do you actually need CAN connectivity and/or sensor feedback?
  • Do you need a full FRC control system, or would something simpler and less expensive like a Cheap & Dirty control system do the job?

Depending on how elaborate your project is, it might make sense to keep your control system as cheap and simple as possible.
Our “Demo Bot” is a dual-barrel T-shirt cannon that we control with a Cheap & Dirty control system and some Spark motor controllers we had kicking around (they send them in the kit every year but we rarely use them, because CAN). We were able to control the drive motors on two axis of the controller, we use another axis to control the shot angle, which is powered by an off-the-shelf (but not FRC legal) linear actuator, and we use the trim dials (which we converted to buttons) to toggle the pneumatic valves for the cannon barrels. The entire system was really simple to set up and use, and the best part is, you turn it on and it’s immediately ready to go (no waiting for the RoboRIO to boot or the AP to connect).

Can you elaborate on what you mean by this?

Yea meant to say the Victor Spx. Thing is the spark controllers are currently out of stock and idk when they would restock. So I might just stick to victor spx.

The control system definitely can be cheap. I was planning on an arduino cleverly controlling multiple mosfet transistors which can each switch up to 15 A. The arduino will provide the PWM signal as well.

The way I know is that when providing motor control with PWM, u are sending current in pulses specified by ur duty cycle (from 1-100%). A smaller duty cycle means for one period of the cycle/square wave (determined by frequency) u are sending current for a smaller fraction of that period.

So in essence saving battery since u are not continuously sending current 100% of the time and also slowing the motor as a result.

Are you referring to the power taken up by PWM signal itself? Not the motors it controls? If so, I seriously doubt you’d even be able to notice the difference between PWM and CAN, such wiring is by far the least significant power draw on any control system.

If you are referring to differences in the power consumption by the motors using PWM vs CAN, could you explain further?

Yea I’m referring to the power consumption by the motors. I don’t know too much about CAN.

I just mentioned earlier in respect to battery consumption that powering motors with PWM is nice for the battery usage since the motors aren’t receiving current 100% of the time depending on the duty cycle.

Parades are hard on FRC robots. Heat. Asphalt. We’ve done a few of these. Much harder on the machine than running near continuous for hours at a STEM night.


You’re basically correct but a little misguided I think. Because the motor acts as an inductor, it tends to resist changes in current passing through it. This has the effect of averaging out the PWM’d voltage we send to it because that’s at such a high frequency (~15kHz.) So in essence we can understand anything less than full throttle as a lower voltage applied to the motor, eg 50% duty cycle is 6V. Because we apply a lower voltage, the motor can draw less current, which in turn draws less from the battery, draining it less.

So PWM isn’t the method by which you’re saving battery, the real saver is running at a lower throttle which we achieve by the method of PWM.

1 Like

Because this is a non-FRC environment nothing says you can’t split up your power system.
One battery for each side and one for your other systems.

I would also use Mini-CIMs. Since our switch to them we haven’t had overheating problems.

1 Like

Thanks for the reply, do u remember how heavy your whole robot was and what ratio on the drivetrain you guys ran?

I’m not Sam, but 1293 ran six Mini CIMs at 7.31:1 on 6" wheels this year and loved it. Inspection weight was around 90-95 pounds if I remember, so we were probably around 120 fully loaded. We designed that around 15-foot sprints, which is shorter than your intended sprint.

Using iLITE’s spreadsheet linked above, and assuming you’re around 143 pounds fully loaded (the most we see in FRC and probably not totally implausible with that many batteries on board), a 5.95:1 ratio (achievable using AM Toughbox parts in a 3CIM4U) yields a 2.5-second sprint to 26.25 feet (8 meters, roughly) at full tilt boogie and keeps the current draw below 40A per motor after the first second or so.

But then, a 12.75:1 ratio (the max reduction in a Toughbox Mini-derived setup) still keeps that sprint under 3 seconds and has a noticeably gentler curve on both per-motor current draw and total system voltage:

For something that’s going to run 45 minutes, I know which curves I like better.

Thanks a lot for the detailed reply. My robot is going to hopefully weigh around 60 lbs max (including with all the balls loaded). I am planning to run a 4 mini CIM 3.25" omni wheel drive.

I need to achieve an acceleration of 2 m/s^2 (6.56 ft/s^2) . What gear reduction would you recommend to achieve that and also to minimize current draw?

Here was my approach:

  1. Force of Friction = 1.1 (coeeff of wheels) x 28 kg (60 lbs) x 9.81 = 302 N
  2. Torque needed to overcome this friction: T = F x d = 302 x 0.041275 (radius of 3.25" wheels) = 12. 5 n-M
  3. Overall torque is 12.5 N, now distributed among 4 cims = 3.125 n-M per motor

So im thinking I need at least 3.125 n-m of torque on the wheel axle to overcome friction.

Any ideas what gear ratio would be able to accomplish this to enable the robot to sprint an 8 m sprint in 3 seconds therefore accelerating about 1.77 - 2 m/s^2 while minimizing current draw.

60 pounds when an average FRC battery weighs 13 means your three-battery robot will have to weigh nearly nothing or something else changed too. But let’s roll with it.

Plug that into the iLITE calculator, and a 7.7:1 ratio is as fast as will get you 8m in 3 seconds. Switch to 4" wheels, and the max ratio goes to 9.4:1 which should open up more COTS options. In either case, go with the highest gear reduction with an acceptable time to minimize current draw.

COTS gearboxes with a 7.7:1-or-smaller ratio:

  • AM EVO Slim (7.56:1)
  • AM Toughbox family (7.31:1)
  • VEX clamping gearbox (7.2:1)
  • VEX Single Speed, Single Reduction gearbox (7:1)

You can do the gearbox calculations yourself, using Vex’s DC Motor Testing Data for the Mini-CIM. Anything over a 2:1ish ratio is going to give you enough torque for straight line runs (if you need to turn, you’ll need to take into account the increased friction from scrub, which would increase the ratio needed). As a rule of thumb, with 4" wheels I would look for a 5:1 or 6:1 reduction on an FRC-weight robot - with smaller wheels and a less weight, you could get by with less.

You can model the robot’s motion a couple of different ways, depending on how you think it’s going to work out. Essentially, it’ll have 3 phases - acceleration, steady speed, and deceleration - while being stationary at each end. On one extreme, you could model it accelerating the entire distance and stopping on a dime(ish). On another, you may accelerate half the time, decelerate the other half. You could accelerate for some period of time, run steady, then decelerate for some period of time.

You can use the JVN Design Calc to run through some options. On the Custom 1-speed Drive tab, you can select the Mini-CIM, set your weight and wheel diameter, and then your gear ratio. The “Drivetrain Adjusted Speed” is a good approximation of the max constant speed you could sustain (does not take into account acceleration/deceleration), and the “pushing” current draw per motor is the most current the motors would take given those settings, if you drive into a wall and stall them. You want to cover 8 m (26.25ft) in 3 seconds, or 8.75ft per second. You can reach that (ignoring acceleration) with a 7:1 (ish, it’s actually a little more, but I’m sticking with nice, round numbers where I can) reduction or less.

The trickier part (for me, at least), is avoiding breaking traction when you start up. You probably won’t be able to give it full speed from the get go, you’ll need a ramp up function to avoid spinning the wheels without moving. I’ll be honest, I don’t know how to model that properly, or figure out what the acceleration/deceleration rate would be. I know some top teams do calculations around it, but for most teams that level of detail is overkill when they can just rely on some basic experience and rules of thumb and still get good performance. Additionally, we’re usually focused on traction impacts in a stall/near-stall condition (pushing against a defensive robot), not in acceleration.

Something else to consider - can you start the robot off to the side a little (a few feet?), and stop past the other side a little? if so, you can use that to soak up some of the acceleration/deceleration, making sure to set up the robot code so it still only shoots within the lines (perhaps using a sensor to detect the lines on the court?) That would make the whole thing a lot easier to manage.

Edit: I haven’t seen the iLite calculator before, I’m going to have to play around with it.