V5 render release thoughts

Thoughts and reactions (Note: for an odd reason, I happen to know some yet unreported details)

Well, but why? For example a passive mogo lift means you need 6 individually-addresable ports just for the drivebase. With significantly more powerful motors, you could use just one for MoGo and 4 for drivebase. And only 3 different control values, though forget about Y cables in V5.

IMEs? Noone in the know for obvious reasons coughI2Ccough.
Quads, pots? Half of the motors for all teams that want to stay relevant.
Now consider that you’re getting the promise of the IMEs with precise axle tracking but without an additional cable and/or more input ports consumed, while also enabling extra features of fast local PID, motion planning and system voltage compensation for free. And using reliable, industry proven communication bus that is actually suitable for the task, unlike I2C.

14V battery (higher system voltage generally) is what enables the RJ11-like connector, I’d be worried about passing the motor currents through that contact spring otherwise.

Can’t wait for those off-the-shelf curled cables on the long lifts. As long as the standard RJ11 fits the bill and not a different, custom-made one to support the motor currents. But 14V battery (higher system voltage generally) should make that more realistic.

Happens in many industries all the time. It’s called progress.
Also, sticking to outdated tech is usually the more expensive option. Plenty of 8bit micros of yesteryear are currently more expensive than better, faster, more efficient and easier to work with ARM MCUs, for example.

Actually, I wonder what will be the coding options for V5 and what will be published of the internal architecture? Besides VEX Coding studio (which, from what can I find looks more like ModKit with text option), I would expect RobotC as well. What about community options, like PROS? My students were about to start migration to PROS, but given the new hardware and likely architecture in V5, that might take time to catch up…

See this. I promised to not share more before the reveal, but this was public before. Also that piece was a prototype…

with the power that the V5 motors I could probably accomplish the same things with about the same performance, just very differently. As for why I need 10 individual ports now, well I might do a reveal later (if it ends up working well enough to be worth it).

PROS support has been confirmed

Yes the connectors for the motor are RJ11 connectors.

We will have standard cable lengths like VEX IQ AND a bulk cable option with connectors and a crimper sold directly by VEX so you can make your cables the exact length you want. As far as rules for VRC, I don’t remember where we settled on using commercial cables, but I expect that should be allowed. I’m not certain the curled cable types will be legal, but equivalent cables to the bulk cable VEX provides should fall under the current rules today as legal. Again, we have not finalized this level of detail in the game manual yet.

The battery connections are custom 1 x 4 Molex connectors based on their industrial 2x2 design. the battery has the charging circuit inside and does not have an integrated cable. So the battery and the brain have the same connector.

As far as software, there will be a full blown (well not ALL of the libraries) C++ inside VEX Coding studio in addition to the blocks and code safe text. The blocks and code safe text will be back and forth compatible to assist in the transition from block to text programming. So there will be three languages inside VEX Coding Studio to start. I suspect we will add more as the community requests it. Also, RobotMesh and PROS will be supported by those organizations right at launch as we have been keeping them in the loop on the development.

We are still doing a bunch of verification testing on the motor curves, but 10W of power at max power is the min we are getting now. This is 10W over a large range of speeds since we are using an oversized motor and limiting its output with the motor firmware. You should be able to get 10W across 50% of the speed range. This will make it seem like you have way more than 2.5 times the power of the 393 motor. So there are no PTCs in this design as we are protecting everything with firmware like we do in VEX IQ.

Also, the motor controller’s FETs used in the V5 motor are running at a significantly higher chopping frequency so in pure PWM mode you have a linear response. However, I think you will find the closed loop speed control mode and position control modes will be much more useful.

I will get the particulars on the communication rates, but please remember that the motor has its own processor so the communication rate between the motor and the brain does not need to be that fast because the motor is doing a lot of the math for things like PID, etc. Again, I don’t have those numbers committed to memory so I will get them when I get back to the office on Monday.

Perhaps now VEX is becoming too easy…

Care to elaborate here?

It actually quite complicated to place a single number on this, but for all practical purposes the motor communications rate is 100Hz.

what I think he means is a bunch of the software stuff that programmers would have to do is done for us already in V5.

So a user level PID loop could run at 100hz and all the built in PID also runs at 100hz? A lot of the discussion previously had lead me to believe it wasn’t the case.

Yep. Also a bit too “plug in and play” for me. V5 will make VEX EDR look even more like toys than the complicated machines they are.

For those of you who were not around for the transition from the PIC controller to the Cortex, VEX took VERY good care of their existing customers during that transition. It was actually a real selling point for me when I visited schools and talked to teachers about why they should invest in VRC.

I’m delighted to read Paul’s comments in this thread. It sounds like VEX and RECF are working together to ensure that we’re going to have another smooth transition. I am particularly impressed with the decision to allow – encourage? – custom length cables. Crimping makes life easy. I also appreciate how having a microcontroller built into each motor might help reduce issues with teams who don’t quite get the point of “sport” making illegal motor modifications. Oh, it will still be possible… cheating is always possible… but it might make it more difficult and/or easier to detect.

And the students who built awesome robots using the original VEX motors (no, the 393 was not an original motor…) will be looking at some of these specs and making some kind of comment about “kids these days”.


Well, I would like to hear the answer from someone official. Paul said that they have limited compatibility and not recommended for competition in an earlier comment so I am waiting for the official answer on this one.

That was my next question - no PTC and allowance for directly controlling driving the PWM (as an advanced mode) means that either you can escape that 10W firmware-imposed limit, or that the firmware could still limit your PWM command.
Now, that could make it even easier to cheat and harder to detect - firmware in the motor is likely to be upgrade-able (as it is in Vex IQ) and it takes one skilled hacker to modify the firmware to sidestep the protection. You can then replicate that to any motor easily and:

  • No visible modification - you just plugged in a cable and uploaded a modified binary.
  • Easy reversal - just flash the original firmware.
  • No testability - require a protocol extension to enable the hack - under normal commands, the motor would behave to the specs.
  • Easy cover-up - in case the hacked firmware and the protocol extension leaks, require a customization with a team’s selected secret key.

I am pretty sure hacked smart motors were utilized in VexIQ before. Don’t ask me whether through the firmare hack (IQ motor firmware is like 6kB, less than 2k MSP430 instructions, easy to reverse engineer) or by replacing the current sense resistor, but the performance of some robots on inclined planes in last two VexIQ games was out of different world.

Now, firmware hacking could be prevented by encryption and signature checks in the bootloader and in the protocol, but I am not sure VEX wants to go those lengths (and I like a little more open nature of VEX much better).

Thanks @Paul Copioli for the info.

Are the new motor screw holes 8-32 size? Is it just one screw holding the motor?

Will there still be partner joysticks? Or just one per robot now? Are the LCD screens programmable? On primary only or both?

You mentioned a new programming environment. Is this taking over Robot C? Does it support IQ and VRC or just VRC?

Can you make a summary thread in a few days? This one is blowin up with lots of great stuff! We charged a bit more this year knowing we would have the trade in program. This cost estimate helps us a ton in planning our upgrades. It will be a big box of cortexes coming back at ya.

I will make a full wish list of the competition bundles based upon our orders for the past few years. You have a wider view of what is ordered I am sure.

If IME’s are in the motor, then we would want potentiometers, a limit switch, high strength gear sets, some sprockets and chains, shafts and high strength shafts with bearing blocks and nylon spacers, an improved gyro, bar locks (and maybe a HS bar lock), corner connector gussets of various types, battery clips, battery extension cable, grippy wheels, and middle sized omni wheels. Oh, and nut drivers.


@nenik I would like to learn more about why you think VEX IQ motors may have been hacked. Can you email me? James Pearman has my email address.

The way the robots behaved on the ramp was by design in the motor.

You said that the goal is for the motors to fail when the brushes fail. Will Vex be selling replacement motors/brushes for those who are inclined to replace them? Therefore we wouldn’t have to purchase an entire motor assembly.

I’m interested in how pneumatics will fit into the V5 system. I’m a bit concerned about the 8 motor vs 12 motor difference. Depending on what the next game is, it might be more advantageous to have 12 motors because it just inherently increases the number of subsystems that it is possible to make. However, if it turns out to be 8 V5 motors + pneumatics like it was before NBN without trading off motors, that could really offset that difference.

On the topic of pneumatics, will there be an pressure gauge? A legal mechanical one that you can read just looking st the robot would be cool, but a digital one to tell the robot the pressure would be really nice.

Can we finally use digital 3&4 with an encoder while doing the same on ports 9&10? :wink:

@Paul Copioli at High Torque 100 RPM how much more will the stall torque be of the V5 motors than on our 393s at the same speed

I was concerned about the number of subsystems also, but I don’t think it will be so bad, the motors being more powerful means we don’t need as many motors a given subsystem.

From a post earlier in this thread by Paul Capioli, “By rule, the amount of 393 motors V5 teams will be able to use is exactly 0.”. Not sure how you can get more official than that.