CIM Motor for Intense Direction Changes

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.

TW

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.

2 Likes

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.