Today I want to relay some more useful information from the awesome jpearman on the VEX Forum regarding motor ports 1 & 10 that will affect the way you’ll want to allocate ports in your robot design.
I seem to be writing encyclopedic posts lately, so here’s today’s table of contents:
- Inside the cortex: 2 CPUs and what they do
- Inside, outside, not the same: jpearman’s oscilloscope graphs comparing reaction speeds of internal & external motor controllers will knock your socks off
- In practice: what to do with all this information
- But wait! There’s more!: power vs. RPMs for internal and external motor controllers
- Conclusion: gotta wrap this up eventually
Anyone who has looked at the motor ports on the cortex for more than 5 seconds can see that ports 1 and 10 are different than the rest, namely that they are 2-prong plugs instead of 3-prong. That’s because the motor controller for these ports is built into the cortex instead of being an external doo-dad that you have to install between the 2-wire motor and the 3-prong motor port.
As described in one of my first Coach’s Corner posts, “What are motor controllers?” these devices regulate the electricity flowing to the motor as a way to control the motor’s speed. Simply stated, it’s your volume dial. If you set the motor to 127 power, the motor controller sends power to the motor 100% of the time; if you set your motor power to 64 (half of 127), the motor controller cycles on and off rapidly to send 100% power to the motor half the time, and 0% power to the motor for half the time. The current flowing to a VEX motor is pretty simplistic: there are only two possible states, 100% power and 0% power flowing to the motor. Motor controllers achieve every power level between 0 and 127 by varying the proportion of time that the motor receives all or nothing. The motor controller cycles on and off so quickly that there’s nothing noticeable to the outside observer.
Inside the Cortex
The cortex actually has 2 little computers in it: the User CPU and the Master CPU. Per this other jpearman VEX Forum post, these 2 CPUs have their responsibilities divvied up as follows:
|Master CPU||User CPU|
|VEX master code (same for easyC & RobotC)||User program|
|Motor control||Digital & analog I/O|
|USB communication (VEXNet & WiFi)||UART (LCD screen)|
In order for your robot to function, these 2 CPUs have to talk to each other, and they do that about once every 15 milliseconds (ms). From the table above, we see that the User CPU runs our program, where, say, we set motor5 = 127 power. However, also from the table above, we see that the Master CPU is the one that actually makes the motors work.
The motor controllers then have their own pulse timing delay on top of this 15ms inter-CPU timing, so adding these together, it is possible that there could be a sizable delay between the instruction from the User CPU to reality on the robot.
Ports 1 & 10 really are special
As stated above, ports 1 and 10 have motor controllers built into the cortex, and don’t require the external motor controllers of ports 2-9. What jpearman points out in the first thread linked above is that the motor controllers inside the cortex are connected directly to the User CPU, so instructions to ports 1 and 10 do not require communication between the User and Master CPUs, but rather get right down to business.
Inside, Outside, Not the Same
Wow, let’s say that again. The motor controllers for ports 1 & 10 are connected directly to the User CPU, involving no communications delay; the motor controllers for ports 2-9 are out on extension cords—with their own PWM (pulse width modulation) cycle timing—that first require communication between the User CPU and the Master CPU, which occurs every 15ms. In this VEX Forum analysis, jpearman estimates that motors on ports 2-9 have (at best) a 15ms delay in receiving information, whereas ports 1 & 10 may be getting updated as fas as every 2ms.
He then did some oscilloscope traces, which are shown below. Yellow = signal, telling the motors when to change speed; blue = port 10; pink = port 3. In the first test here, he changes the motor speed repeatedly from 127 to -127 every 40ms. You can see from the graph that the port 10 motor tracks the signal precisely, whereas port 3 has a significant delay and results in rather random amounts of time at each speed, shown by the uneven lengths of the horizontal bars in the graph.
Next he upped the stakes, and did the same test, except told the program to reverse direction from 127 to -127 every *4* milliseconds. The results are even more dramatic:
It can be seen that the motor on port 10 is able to keep up with this increase in changing requested speed; however, the motor on port 3 is not able to and changes randomly depending on the relationship between the motor speed request and the SPI message being transmitted to the master cpu [the timing of the communication between User & Master CPU].
Um, wow. That last graph kinda leaves you speechless, doesn’t it? That’s the difference between receiving instructions directly from the User CPU versus instructions waiting to be sent from the User to the Master CPU (to coincide with the every-15ms communication frequency), combined with the delay from when the instructions are delivered from the Master CPU to the external motor controller, which might also have to wait to coincide with the controller’s PWM cycle.
Last year my daughter was building a robot for her science fair project, which had a holonomic chassis. It was the first time either of us had built a holonomic drive, and we didn’t know much about any specifics (“How hard could it be?” Ha ha.). We happened to be low on either extension wires or motor controllers, I can’t remember which, so we plugged 2 wheels of the chassis into ports 1 and 10 and 2 wheels into some of ports 2-9. Oh My God it was the most horrible-driving jerky spastic thing you could possibly imagine. It was a complete disaster! And it took us a LONG time to figure out that this was the problem, since this was the first time we had ever used ports 1 or 10 on any robot. (We figured it out by process of elimination; after you strip things down to just a chassis & holonomic joystick block, there are a finite number variables in play.)
Looking at the graph above tells the whole story! Yep. Don’t need to wonder any further…
To restate the obvious, in case you’re skimming this post, DON’T COMBINE PORT 1 & 10 MOTORS WITH PORT 2-9 MOTORS IF THEY NEED TO MATCH SPEED OR BE COORDINATED WITH EACH OTHER. Use ports 1 & 10 either for independent mechanisms, or for a pair of motors that work in concert, such as 2 motors that raise an arm. Do not use a combination of port types for a lift, or for your chassis, or for any other part of your robot that is supposed to function as a unified system (and especially not for a holonomic drive!). It just won’t work.
At the very start of jpearman’s first post above regarding ports 1 & 10, he mentions that these 2 ports would be good to use for a system employing PID control because they respond so quickly and are so sensitive. Looking at the second oscilloscope graph above makes me want to do a facepalm when I think about our Nothing but Net flywheel from last year. It was horribly unresponsive, massively slowing down after a ball got shot through. We attempted to employ a PID algorithm to keep it at a constant speed, but there was no algorithm in the world that was going to get our flywheel to regain speed fast enough. Had we known about how differently ports 1 & 10 respond to instructions, we would at least have given them a try before abandoning all hope. (We ended up using a limit switch instead to sense when a ball was exiting the flywheel, and gave it a large burst of power to compensate; it worked well in the end.)
But wait! There’s more!
In yet a third VEX Forum post, jpearman did some speed testing on a motor plugged into port 10 versus one with an external motor controller. [He did this particular testing before the introduction of the current 393 motors, but there’s no reason to think that the results would be much different.] First, here’s the output graph (x-axis is VEX motor power, y-axis is motor RPM):
This graph show various important pieces of information:
- At a given motor power, a motor plugged into port 10 and a motor plugged into, say, port 7 will run at different speeds; the one plugged into port 10 will be slower (blue line above).
- Based on the information from the oscilloscope graphs above, however, we know that the motor in port 10 will be more responsive to instructions from the user program.
- The motor in port 7, with the external motor controller, will not get any faster after about 90 power, so motor7 = 90 and motor7 = 127 will produce approximately the same RPMs.
- The motor in port10 will increase in speed all the way up to 127, so motor10 = 127 will go a teeny bit faster than motor10 = 126.
The above figures are all based on a testing environment, so must be taken with a grain of salt, but it is generally accepted that speeds on the external motor controllers definitely max out somewhere north of power 100 (maybe less?), and that you will not get any performance improvement (other than psychological) by increasing your motor from, say 105 to 120 power.
As noted, the graph above was made using the older 269 motors; there’s a quadrant of an updated graph (below) showing the motor controller line only for the 269 and 393 motors [note: this graph does not include any information on ports 1 or 10, though it unfortunately uses the same color scheme as the graph above]. As expected, the new and old motors have very similar curves, and max out at almost the exact same power level. The newer 393 motor does not achieve the same maximum speed as the older 269 motor, though it does show more responsiveness in the lower power levels.
Conclusion of this (once again) very long post
In my previous post I encouraged mentors and coaches to surf the VEX Forum when you have the time. I came across the oscilloscope images above while I was following a thread from another, newer post, and my eyes just bugged out of my head! I couldn’t believe the difference between the 2 motor controller types, and once I read the various explanations, so many other things fell into place.
I learned so much just following the threads through that I wanted to compile it here so that it was a little more digestible, and all in one place in lieu of being spread across multiple Forum posts and comment threads. Again, a debt of gratitude goes to jpearman for the countless hours of scientific research and testing that he has done to educate the rest of the VEX community. I hope that you find this information helpful as you are thinking about your robot for the coming year, and I hope that the basic explanation offered here about how the communication processes happen inside the cortex is of value (see my earlier post on IMEs for details on how the cortex talks to the IME daisy chain).
As always if you feel that I’ve missed some important information, or I have written something in error, please email me and I am more than happy to edit this post; my interest is in spreading knowledge and helping to educating other coaches and want to have complete and accurate information.