According to this post the cap per motor is 20A / number_of_motors. At this time it didn’t matter if the motor was in use or not it still took up some current, has this changed?
If this hasn’t changed, if I were to use a 14 motor bot for VexU each motor would be capped at 20A / 14 or 1.43A per motor, significantly less than the standard 2.5A.
If I take it further and say I was going to have a:
6 motor drive (8.57A)
4 motor intake (5.71A)
2 motor lift (2.86A)
2 motor tray (2.86A)
and pair that up against the “standard” bot this year:
4 motor drive (10A)
2 motor intake (5A)
1 motor lift (2.5A)
1 motor tray (2.5A)
This is essentially just moving some current from the drive to the other mechanism in the robot. My question is really how much do amps really impact the motors and if it’s even worth using more than 8 motors for VexU if the amps are as important as I’m understanding them to be.
I believe you would have an overall increase in power regardless of the number of amps wasted.
However, think about each of these components:
For the drive, 4 motor is just as viable as 6 motor, they are each so strong it hardly matters which you use.
Intake-wise, I’ve seen teams intake 11+ cubes with the standard 2 motor intake, depending on build quality, so rather than using 4 motors, you might just stick to 2.
2 motor lift and tray will be fairly helpful, I would keep those, but for max viability, I would use 10 motors total:
4 motor drive (8A)
2 motor intake (4A)
2 motor lift (4A)
2 motor tray (4A)
Good question! I look forward to seeing how other VexU teams tackle this challenge.
vexos 1.0.9 uses a different algorithm than versions 1.0.8 and earlier.
8 or less motors are still capped at 2.5A.
9 or more are capped as follow, remember this is current at the motor not current from the battery,
However, those values are only valid if user code has not set current limit lower on one or more motors. If that has happened we take the user specified lower motor current into account and compensate in the calculations accordingly. For example, a situation with a 20 motor drive where 8 of the motors have current limit set very low (say 500mA) allows the remaining 12 motors to all be capped at 2.05A
In addition to the above. In all cases we monitor total battery current. If we see a high current situation for more than 2 seconds, we cap all motors at a lower value, that’s currently 2A for 8 motors or less and 200mA less than the calculated value for 9 or more motors (ie. the 20 motor value would be dropped to 1.45A ). This additional limit is removed when we see the battery current drop.
Just a question; Does the current algorithm apply when the motors all are running or immediately when the motors are plugged in? ie, if you plug in 20 motors, if you run only one motor will the motor cap at 2.5A or would it cap at 1.65A? In addition, would the current calculations also be modified based upon the voltage you apply to a motor?
@Connor, how would you compensate for dynamic current cap in auton? Or, if you added a new step like lifting while driving, etc?
@jpearman, last years team connected the drive motor to the 1,10,11,20 ports b/c they were closest to the motors. I surmise that to have access the full current the drive motors should be connected to port 1-8?
If I were a part of a VEXU team, I may possibly assume that the system would automatically re-compensate the current depending depending on how many motors are running, and not how many motors are plugged in. I actually assumed the latter before you clarified that the current compensation is not what it seems to be. All Im wondering is if theres a possibility to have the robot re-calculate depending on the voltage applied to the motors? i.e: If one motor is told to go 12V and another is told to go 6V, shouldn’t current be re-applied to a manner that suits the voltages? Basically, Im thinking along the lines of:
Grab the theorhreatical total voltage that is desired from the motor system
Grab the percentage of voltage each motor is desiring to use from the theorhetical total voltage
Grab the max possible current the Brain can apply to the motor system
Apply the percentage onto the max possible current the system can handle to each individual motor (And of course at the same time having a max cap for the motors to 2.5A, so if there’s less than 8 motors then it will prevent over-currents) and that will be the current cap.
And have this continuously check and re-apply. Why exactly is the system not applying continuously rather than a mere “plugged in, reduce current cap for all motors?”
so most of the time teams are not sending a voltage to the motor but rather a requested velocity. Even when the motor is told to stop, it may be using a significant amount of power depending on the brake mode of the motor.
The current limiting happens inside each motor, even when we limit continuous current to 2.5A, the transient current can be much more than that and the motor needs to respond quickly to these changes. Individual motors don’t have knowledge of what all the other motors are doing, communicating that data back to the brain and then out to all motors is not something we can easily do and there would be significant latency.
so we have moved some of the current management to the code the VexU teams write, if they know that one motor is being used and 19 others will not, they can set the current limit for those 19 to be very low and then the remaining motor will have full power available. This is easier for a team to control than having vexos guess how and when motors will be run. There is a limit to how often this can be updated, but that’s up to VexU teams to determine. We could have allowed a little more motor power, however, our testing showed that there was a possibility of the battery going into a protection mode and shutting down the brain, seems that’s not something a VexU team would want to happen.
Ok, I see. I thought that since the total was more than 20A, the first 8 ports/motors would have a higher limit. But since each motor can have its own current_limit, there is no need to have VEXos have different limits as a default.
Any chance you could have this task assigned a priority? Otherwise it’ll always be too far down the list to ever happen. As noted by sazrocks VEXU teams would benefit from knowing what the black box does rather than having to make assumptions or burn time characterizing it.