VEXU - Maximum amount of motors safe to use on V5 system

Hello,

I am competing in the VEXU competition this year. We don’t have a limit to how many motors we can use, but I was concerned that using too many may fry the brain. What is the maximum amount of regular motors you can use without risking frying the brain? Also what is the maximum amount of torque/speed motors you can use without risking frying the brain?

I have not heard anything about frying the brain per say, but it can only handle 10 motors running at full power at a time (atleast that’s what the other vexU teams say)

1 Like

The firmware, both in the motors and Brain, should limit power draw to a safe level to prevent any damage to the Brain. So you shouldn’t have to worry about it, aside from knowing that, if you are trying to run many motors simultaneously, you will not get full power out of them.

4 Likes

FWIW I saw VEXU robots in Turning Point with as many as 18 motors.

One robot had 22 motors :grinning:
Depending on their starting tile they would swap 2 ports between four motors.

3 Likes

What on earth do they need that many motors for?

2 Likes

I don’t know but I would have spinning flags.

3 Likes

You can use as many motors as ports there are, but once you get over 10 the motor won’t run at full power. So I think if you use 20 motors, but only power 10 or fewer at any given time they would run at full power.

@freddebakey V5 Battery specification states that it is rated at 20A max (old 7.2v batteries are just 8A for comparison).

You can query the actual current supplied by the V5 battery with pros::battery::get_current() function.

Similarly, you can query the current for each motor with pros::Motor::get_current_draw() function.

Default limit for each motor is set at 2.5A - under full load you could draw max battery power with just 8 motors.

However, as long as the load on the motors is moderate and the total current stays under 15A-18A you should be able to use as many motors as you could physically connect to the V5 brain.

Why? Did they plan to transport a VRC field along with all team members to the other side of the gym with that robot? :slight_smile:

2 Likes

The algorithm in this years firmware was simple, if you had more than 8 motors, each motor was capped at 20A / number_of_motors. Using 20 motors on the robot limited each one to 1A max. Next year we may see if we can make this more adaptable and only consider motors being actively used, however, it’s a bit more difficult than it may appear to do that.

11 Likes

I’m not quite sure why so many. It was the christmas tree robot, with like 6 rollers on each side =)

Is there any chance we could get the ability to manually set the current limit for each motor within user software (such that the total doesn’t go over 20A and each motor doesn’t go over 2.5A)? This would allow users to dynamically prioritize which motor gets power depending on the situation and their specific use case (and I would imagine it’s a decent bit simpler then making a general adaptive system).

5 Likes

@Andrew_Strauss, there is pros::Motor::set_current_limit() function. I am sure you can lower it below the default limit, but it would be a question to @jpearman or PROS developers what happens if you try to increase the limit above the default.

Now you have to post the picture, because everyone is very intrigued.

2 Likes

The max motor current we set when using more than 8 motors is independent from the current limit that can be set via user code. There’s certainly room for improvement, we know that. This first iteration was primarily focused on safety and simplicity of testing.

5 Likes

That’s interesting, and not at all how I thought it worked. I thought it worked so that if you had 22 motors but only used 8 of them then those 8 would still run at full power. Is it possible for this to be done in future firmware versions or is this a limitation of the system architecture?

3 Likes

Now that I know about this, this actually explains some of the weird behavior that a local VEXU team’s bot exhibited; my 4 motor drive was somehow stronger than their 6 motor drive. Doing the math, I now see that since their robot had 15 motors, each of their drive motors were limited to 4/3A, whereas each of mine could use the full 2.5A. This meant that despite their drive having 50% more motors, they actually only had 8A worth of pushing force, and my drive had 10A worth of pushing power, 25% more than their’s. Is this behavior properly documented anywhere?

3 Likes

there are so many rollers on each side :smile:
I had a chat with them at worlds, that’s when they told me they have 22 motors.
2 Likes

It is possible, but we have no timeline for implementation. One concern is the delay in getting information back to the brain and being able to take action.

No, but motor current is easily measured in either user code or just by looking at the motor dashboard (less current -> less torque). We figured that VexU teams were smart enough to figure this out on their own.

2 Likes

lol, I guess you guys had too much faith in them

1 Like

It’s not a matter of too much faith. Expecting teams to figure this out on their own is quite frankly unacceptable in my opinion.

If you look at other motor controllers, like the Talon SRX, their datasheets will spell out exactly what current will be supplied under what conditions. Furthermore, if you look at virtually any name-brand electronic component, the datasheets will have far more info than you know what to do with, and only in rare/edge cases will you have to do your own testing of a component.

Obviously neither of these examples are quite like V5, but that doesn’t mean VEX and V5 should be held to a lower standard of documentation. At least with the Cortex, current limiting was done by PTC resistors, so anyone that opened a Cortex or motor could easily figure out what sort of power delivery to expect. But, if the current limiting is controlled by firmware, there’s no way to know what’s going on without seeing the source code or spending far too much time reverse-engineering the firmware/algorithm.

4 Likes