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
The algorithm only exists inside vexos at the moment, if I get a chance I will convert to javascript and put up an online calculator or something to make calculations easier.
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?
@anon4126930, 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?
No, port number is irrelevant, all that matters is total number of motors connected to the brain and what you may have additionally chosen to current limit in code.
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.
Sorry to revive this thread, but is it possible to publish this algorithm? It would be very useful for vexu teams looking to perform their own current limiting.
Additionally, can you define “a high current situation”?
greater than or equal to16A from battery for more than 1 second.
In terms of the algorithm, perhaps, that code was from some time ago and I would have to put it in a form we could publish, check that’s it’s correct etc. and I have a million other things to do.
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.
To be quite honest, it is low priority compared to everything else.
and although the post above does not give the complete picture, It gives a good sense of what will happen.
Sorry for reviving this topic, but I wanted clarification on some stuff posted specially here by @jpearman .
Is this information still accurate for the current version of Vexcode Pro?
I was looking through the vexCode and couldn’t find the command to do this. Could would it just be something like this?
MOTORNAME.setCurrent(2.0, amps);
Additionally, can I change the current of the motors throughout the match and actually see the results? (ex. cut the drive motors down to 1 amp and give all the extra amperage to a hang mech)
I probably have a misunderstanding of how the vex motors work, cause my math isn’t mathing. 2.5A times 12V equals 30W, but the 11W motors only give 11W? What exactly is my mistake here?
And then final question, in the past 2 years has there been an update on this?
Nothing to do with VEXcode, this is all handled by vexos.
and, as of vexos 1.1.2, it’s all still the same. It will be changing slightly in vexos 1.1.3, I’ll summarize below.
yea, it’s a little odd. for C++
motor1.setMaxTorque( 2, amp );
so for High School, this is all irrelevant (except see last paragraph) For VexU, yes you could.
Max output power is 11W, that’s angular velocity * torque.
Input power can be volts * current. However, inside the motor it will not be 12V when limited to 2.5A as the way current is limited is to drop voltage.
So there will be an update that impacts high school in vexos 1.1.3. The issue is 5.5W motors, currently all motors are treated the same so if you have more than 8 motors, because of the use of 5.5W motors, there is technically some limiting. vexos 1.1.3 will address that. But release timeline for vexos 1.1.3 is not locked in yet.
James got the rest of your question but this point here is something I struggled with a while back so I figured I would explain how I understood it.
This is the v5 motor torque/speed curve (among other things). What we care about is the green line, and also that throughout this whole graph, user code is commanding 12v from the motor.
Moving from right to left, the motor is having more and more resistance applied to it, hence the current drawn by the motor is increasing. Throughout this portion of the graph, the voltage of the motor remains at 12v. This continues up until the point where the arrow is pointing, at around 55rpm or so. At this point, the motor electronics start throttling the voltage sent to the motor in order to keep the current in check as the motor’s electrical resistance continues to drop, and this continues all the way to the left edge of the graph where the motor is completely stalled, pulling 2.5A at like 4v from my experience.
The important thing here is to note that the motor did not reduce its voltage until the load caused it to slow down past ~55rpm. Therefore, at around 55rpm, the motor is being fed 12v while also consuming about 2.5A of current. This means that yes, the motor is consuming roughly 30w of power from the brain/battery at this point in the graph. Again though, this does not violate the “11w” rating of the motor, as that is output power as measured at the shaft. So where is all the extra energy going? It’s being turned into heat, in the motor and in the motor electronics (to a lesser degree). When you consider that is roughly 17w (the motor is outputting ~13w at that point on the graph) of heat being dumped into a fairly small space, it’s no surprise that the motor would overheat within a relatively short period of time.
Fun fact, this is where a rarely used portion of the v5 motor’s telemetry data becomes relevant: efficiency. In vexcode (and other programming environments of course) the v5 motor object has a function to retrieve the efficiency value of the motor:
public double vex::motor::efficiency(percentUnits units=percentUnits::pct)
This reading is basically the result of the following formula: input_power/output_power. Essentially, it is a measure of the fraction of the power going into the v5 motor that is actually making it to the output shaft. Maybe this can be used to a productive end in the competition…
As an interested party still competing in VEXU, will there be any effect on how 11w motors are treated for the purposes of the current limit, or is this simply a change to treat the 5.5w motors like smaller motors when calculating the cap?
