Sometimes the VEX IQ Robot Brain displays a message that a firmware update is needed for a device. Before getting started, have the VEXos Utility already downloaded to your Windows or Mac computer. Step 1: Connect the device to the Brain, and the Brain to the computer. To install the device driver. Press “Continue Anyway”. Finalize Installation Press “Finish” to finalize the device driver installation. Note: Once the device driver installation is complete, you should no longer need Administrative privileges on your computer; you should be able to download Master CPU Firmware, ROBOTC firmware.
- Vex Robotics Usb Devices Drivers
- Vex Robotics Usb Devices Driver Win 7
- Vex Robotics USB Devices Driver
- Vex Robotics Usb Devices Driver Windows 7
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 CPUruns 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].
Vex Robotics Usb Devices Drivers
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 port10will 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.
There’s a lot of things I like about RobotC so far, and perhaps the most time-saving item is wireless downloading. In order to make use of this feature, you need to purchase the VEX wireless downloading cable, officially known as the “Programming Hardware Kit.” Cost: $50; I got mine on eBay for about half that — it’s worth it to check eBay every now & then! [EasyC users—you’re out of luck here. Although I’ve read on the VEX Forum of some easyC users being able to make it work on occasion, that software and this component don’t generally work together.]
Why we’re lovin’ RobotC:
- Wireless downloading!
- Wireless debug/sensor data (subject of another post).
- You can actually do sophisticated programming.
- Tons of code available to look at, use, and learn from on the VEX Forum, the RobotC Forum, and YouTube.
As an added bonus, our team will no longer get Forum users answering our easyC questions with “You should switch to RobotC.” Gee, thanks.
A condensed table of contents: (a) Wired vs. wireless; (b) Hardware setup and Cool add-on product; (c) Using it and What’s that button for?; (d) What if it doesn’t work? and (e) Additional resources.
Wired vs. Wireless
Think about programming autonomous—or even better, autonomous skills. 60 seconds of trying to get everything just right with teeny changes and trying again and again. Without wireless capability, every iteration of programming involves the following:
- Move the robot over to where the person with the computer is, or vice versa
- Unplug the VEXnet key; may be more or less of a pain, depending on where it is on the robot
- Plug in the orange programming USB cable
- Unplug orange cable, plug in VEXnet
- Cycle the power off & on for the robot & joysticks, just to make sure it’s gonna work right
- Set up the robot for the next run
With wireless downloading, mirroring the steps above:
- Set up the robot for the next run.
- Click the “start” button on the RobotC debug-window-popup box to enable normal robot functionality and competition switch.
So how does this miracle occur? As shown in the image at right, the cable is a 3-part item—the first section is USB, which plugs into your computer, the same way as non-wireless downloading. The other end of the USB gets connected to a Magic Widget (rectangular orange box, photo at right). The other side of the Magic Widget has a different type of cable (looks more like a large, flat telephone wire) which runs from it to the “Program” port on the back of your main joystick (photo below). Then the joystick continues to talk to the cortex via the VEXnet keys, as it does during driver control.
Here’s VEX’s schematic of the whole thing put together:
Vex Robotics Usb Devices Driver Win 7
Cool Add-On Product!
Apparently the USB that plugs into the Magic Widget is known to come unplugged from time to time, causing grand annoyances in the download process (because you don’t immediately realize it’s no longer connected). One of the VEX teams in this wonderful world will make you a box that holds the Magic Widget and plugs, and prevents them from getting tugged apart—WITH YOUR TEAM NUMBER ON IT! How awesome is that? Woo-hoo! We have one, bright green, easy to find around the lab, works as advertised.
From their online ordering page, you can either download the 3D design (I think), or select one of 3 vendors to print it & ship it to you. Cost: about $8 with US shipping. (If you’re a member of the VEX World Coaches Association facebook group, you can send the creator, Nasir Illasarie, a message if you have questions. If you’re not a member of the group, please join!)
We had a little difficulty getting this item set up and working, and then a little more difficulty getting it to work well after that. So this is why I’m writing this post—hopefully I can save some of you a bit of time on this one.
Do this stuff once:
- Start with robot and joysticks turned off.
- In the top menu in RobotC, go to Robot / Platform Type / VEX Robotics flyout menu and make sure it’s set to VEX 2.0 Cortex
- Also in the top menu go to Robot / VEX Cortex Communication Mode flyout menu, and make sure that it is set to “Competition (VEXnet)“
- [Possible] You may need to install special VEXnet serial drivers to your computer; page 2 of this document describes the steps to install them. I’m not sure if this information applies to the current version of RobotC, Windows, etc. because the document only covers up to Windows 7. However, the VEX product page says that you need to install them (under the “Description / Post-2012 Driver” tab at the bottom of the page).
- Sorry I can’t be more definitive here; I did not do the setup for my team, and the person who did doesn’t remember all of the steps required.
- Probably falls into the “couldn’t hurt” category.
Do this when you wirelessly download:
Vex Robotics USB Devices Driver
- Connect things together as shown in the schematic above.
- Turn on joystick and cortex and let them pair/connect
- Make sure your competition switch is plugged into the “Competition” port on the back of the main joystick and set to “Disable” (for safety; prevents runaway robots in case autonomous starts running after you download the program)
- Click the big “Download to Robot” button in the RobotC toolbar
- Ta-da! Your program is downloaded.
- However, the robot will not respond to the competition switch, and you’ll be annoyed and frustrated that this doesn’t work
- On your computer, after downloading there will be a popup box that looks like the image at right. Click the teeny “Start” button in the top left corner of the box
- NOW the robot will respond to the competition switch and work the way you expect, and you can run things repeatedly, enable, disable, drive with joysticks, test autonomous, the works.
- Additional downloads can be done the same way, and will not require turning off the joysticks or cortex. Be sure to set the competition switch to “Disable” before downloading every time. Safety first!
What’s That Button For?
There is an LED and a little button on the Magic Widget labeled “Program.” Basically, don’t worry about it—you will likely not have to use it. The only description I’ve found was from 2005 and 2006 VEX Forum posts:
The button will force the Vex Controller into a download or programming state and turn the program light on. You are then ready to download your User code. This is not normally required with most computers but it can be used if your computer is having trouble talking to the Program Module, and you cannot get the program light to come on when you are trying to download code.
In short, I think it’s a placebo button. “We can’t get the program to download.” “Try pushing the button.” Followed—probably—by, “It’s still not downloading.” I dunno; don’t sweat the button.
What If It Doesn’t Work?
This setup will, of course, have times when it does not work right. Some error messages we’ve received are below:
Oh great. What do I do now? Our troubleshooting steps—mostly in mostly this order—are listed below. I can’t stress enough the basic tenet of any scientific experiment: Only change ONE THING at a time. If you change multiple things, and your problem is solved, you still don’t know its real source, and it might pop up again, and you will waste time. (I hate wasting time; it’s such a …. waste of time.)
- Don’t panic.
- Read the error message. As you can see from these examples, it sometimes tells you (in a helpful way) what is wrong or what you need to do. If so, follow those instructions; if not, move through this list.
- Turn everything off—robot, joysticks, unplug USB cable from computer (leaving the joystick connected to the computer keeps power going to it, even when the switch is off).
- Turn everything on in the following fashion: (a) re-connect USB cable to computer; (b) robot; (c) joysticks. Let the VEXnet connect again, and re-download.
- Turn everything off and on again. Seriously, not kidding.
- Make sure the robot and joystick have happy green lights. See our VEXnet lights chart that you can print out & keep in your lab for reference. (We even laminated ours.)
- Try a different USB port on the computer, or try a different orange USB A-to-A cable that goes from the computer to the Magic Widget.
- Make sure the 4 ends of the hardware kit are securely plugged in (USB to computer / USB to Magic Widget / Magic Widget to flat telephone-type cord / flat cord clicked into Program port on joystick).
- Press the placebo button on the Magic Widget; who knows, it might do something!
- Unplug the wireless downloader from the joystick and look very closely at the little pins in the Program port on the joystick and on the wireless plug to make sure they’re not damaged. Reconnect and make sure that the wire is “clicked in” to the joystick (i.e., plugged in completely).
- Google the exact phrase that appears in the message box, and you will probably find someone else who’s had this problem in the past.
- Try to download the old-fashioned way, plugging the orange USB cable from the computer directly to the cortex. Does it work? If not, then the problem does not lie with the wireless system, and you need to troubleshoot the source of your wired-downloading issue.
- Change batteries on the robot and/or joystick (even if the lights are green; seriously, you’re pretty far down this list—you need to try everything).
- Turn everything off, REBOOT THE COMPUTER, and turn on/connect again.
- Update the firmware on the robot & joysticks under the Robot / Download Firmware menu at the top of the screen, and tell it to automatically include joystick updates.
- Swap out the VEXnet keys, if you have 1 or 2 to spare. Only swap out one at a time so that you know where the problem lies.
- I don’t know.
Vex Robotics Usb Devices Driver Windows 7
- George Gillard (georgegillard.com), a university student in New Zealand, has created some great documents on his website for download: The Beginner’s Guide to RobotC, Volume 1 and Volume 2 (and others!). Highly recommend; well laid-out with screenshots and examples. Volume 2 gets into more sophisticated topics. Thank you, Mr Gillard!
- Here’s a PowerPoint presentation that has some nice screenshots and has a bounty of useful information on RobotC in general, in addition to walking you through some of the stuff described in this post: ROBOTC for CORTEX Teacher Training.
- As I linked in a previous post on RobotC, the Carnegie Mellon VEX EDR Video Trainer is a thorough and easy-to-understand tour through many facets of using RobotC.
- McCallum Robotics, Team 8756, has created a large collection of RobotC tutorials on YouTube. Very clear and well-presented.
- Search results for RobotC + YouTube.