Hello VEX U participants. This year I will be graduating from high school and look foreword to working on a VEX U robot over the summer. Having only ever used vex sensors in the vex high school competition, I was hoping to get some insight on what other VEX U competitors often use as sensors. Is there better gyros or accelerometers that can communicate well with cortex?
Also for VEX U participants. Is altering vex sensors allowed according to this?
Any other VEX U secrets of the trade?
Thanks a lot!
Yes, there are 3rd party sensors out there that can be more accurate then vex sensors however the ease of “plug and play” with vex sensors disappears. You will be required to analyze the sensors respective datasheets to see if it is compatible with the cortex (logic levels, power consumption etc etc). If it is you will then need to write your own driver to interface with it. Here are some projects that we have done at Purdue in the past.
I’m also considering VexU next year and I’m wondering about the phrasing in the manual. It states that “Sensors and electronics must be connected to the cortex”. If I were to connect some sensors to a processor board (say an arduino or something), and then connect that board to the cortex via a UART port or I2C, would that be legal under this rule?
I think it would be much easier to have a separate processor board if you are making extensive use of non-vex sensors. That way you can easily break out multiple interfaces like I2C, SPI, and USARTs.
Yes you can alter VEX sensors to your hearts desire. We modified the housings on most of our sensors to get them to fit where we needed them. We experimented with other gyroscopes for this season as well but that never panned out. You would definitely want to use an Arduino to handle the processing for anything advanced. The cortex doesn’t have a whole lot of power behind it.
I need to correct you here as that is not true. The Vex Cortex has a lot more processing power and speed with its ARM Cortex-M3 processor then any of the Arduinos. Lets take a look at some of the hardware specifications and stats.
Here is a comparison of the hardware specs of current revision Arduino vs the Vex Cortex
As you can see the Vex Cortex has more flash storage, ram, and a higher operating clock frequency. It is also worth noting that the Arduino Uno and Arduino mega utilize chips with an 8-bit architecture vs the Arduino Zero and Vex Cortex which have 32-bit architectures. Now lets look at the speed of each of these chips in how many instructions they can do per second. The unit of measure for this is MIPS (Million Instructions per Second)
Again you can see that the Vex Cortex surpasses all current revision arduinos. Also it is worth to note that I have a range on the Arduino Zero due to the fact that I could not find the exact MIPS measurement for the chip that Arduino uses and instead based it off of the efficiency range given for the Cortex-M0+ chip.
Now is the vex cortex the most powerful embedded system out there? No, it isn’t. Boards such as raspberry pi and beaglebone black as mentioned earlier have more processing power. However these boards are not microcontrollers but in fact single board computers running Linux. This is a bit of a disadvantage in robotics as we know Linux != realtime. Where as the Vex Cortex is in fact realtime with all environments on the market (EasyC, RobotC, PROS, ConVEX).
tldr: Vex Cortex in its age is still a very good platform for its job
Apologies for my wording. I should have clarified that with how our code was setup this season, it was handling too many actions at once which caused issues. Really, this was an optimization issue on our end. However, I was unaware that it was that much more powerful than a Mega! I’m an ME, so this is certainly not my area, so TIL! Also, nice seeing you on here, Jabibi! I was hoping to run into you at Worlds, but unfortunately got too busy making sure our robots are actually functional. I’m the guy on ODU robotics who had the video of the DQ’ed match at your qualifier in February!
Thank you for the answers and extra details guys. I’m curious about one more thing - how far does the “no restriction” on sensor usage extend? As an example, say I wanted to use a non-vex motor encoder for higher resolution tracking. However, the encoder I want to use does not have the necessary mechanical interface to connect directly to the Vex axles. Would the sensor rule allow me to use off the shelf mechanical parts to connect the encoder to the Vex axles? Or would I have to use another method allowed under the rules explicitly like 3D printing?
Using a mechanical adapter to interface an after market sensor is allowed as it is “part of the sensor” however I from my interpretation and past experience additional mechanical components such as sprockets and gears that are non vex (and not 3d printed) would not be considered as “part of the sensor.”
We’re really close to starting a VEX-U team this season, so I need to get up to speed. Outside of the VEX EDR sensors, my experience in controls/sensors is all industrial, and everything I’ve used runs on 24 VDC (~18-30 VDC by specification). Do you guys just use a DC to DC converter? Or is there another popular collection of sensors to look into?
I would look mainly for sensors that people online have interfaced with arduinos. Most hobby digital or analog sensors should work at 5V so it should be pretty easy to find what your looking for.
In all honesty for simple digital or analog sensors I would actually recommend the VEX sensors, they are actually incredibly good. If you would prefer say an analog ultrasonic sensor or IR sensor to a VEX digital ultrasonic sensor look on sparkfun or polulu for cheap simple stuff. Anything beyond simple sensors UART or I2C is going to be the way to communicate and those are both so standardized I can’t imagine you would have much of an issue. The lidar we used could handle 3.3V or 5V logic level which saved us the hassle of needed an in between board for communication.
In all honesty while people often use a cool new sensor occasionally most teams stick to VEX stuff for
pots
encoders
buttons
line followers
I would use third party pots if at all possible. All of the vex ones (10+) my school has used have all broken just by them not securing properly or the limits being useless to actually protect the sensor. The limits on higher quality pots actually could stop something, while the flimsy tabs in the vex ones just snap and then fry analog ports.
I mean I guess if you are going to use them improperly sure. I always love the Vex pots. The form factor and having the axle go through the pot make it very convenient. By the time you 3d printed square shaft interface a 3rd party pot would be pretty big.
If you do want to look into 3rd party sensors for VEXU, I would say looking at what different sensors are commonplace in FRC. Some sensors in FRC still will not interface easily with the cortex so you have to keep that in mind, but it can be done. I think things like thru-beams, proximity, etc. is great to look at; VCAT used things like that very well this year.
A great example I can give is an alternative to the VEX encoders. This past year we used the US Digital S4T Encoder that is used frequently in FRC. The quality is much better and the footprint is much smaller which can come in handy. Things like built in ball bearings on the shaft, high CPR, etc. make it a great product. Mechanically to interface it with the VEX products there’s a couple ways we made that work. One way was to 3D print some couplers that pressed onto the encoder shaft and had a slip-fit square hole for the vex shaft to slide into. Another way was to take the 1/8" shaft couplers that VEX sells, and on one side, machine a set screw hole so that you can lock the coupler onto the encoder shaft. Then you can just slide VEX shaft into the other end.
Another example that we played around with (although did not compete with) and something I know BNS used in competition is the PIXY camera. It was used to vision track balls on the ground for autonomous. Definitely takes a lot of effort to get something like this to work, but in the long run could be very cool. I always wished last season that VEX had put some kind of reflective tape on the goal similar to what is used in FRC games so we could have seen some really cool auto-aiming robots on the VEXU stage. Unfortunately without some kind of aid added to the goal the mesh just proved too hard for a camera to grab.
Honestly using 3rd party stuff is just going to be a “you get what you put into it” kind of situation. You can definitely find better quality versions of the VEX sensors* as well as other sensors VEX doesn’t sell. However if you don’t leave yourself the time to implement them properly they won’t do much for you.
*The VEX Bumper sensor is fantastic. It’s incredibly durable and I’ve never seen one fault on its reading. I know many really elite FRC teams that use them because there isn’t much better out there. The limit switch sensor is also just fine, a limit switch is a limit switch. We’ve also found without spending a ton more money the VEX Gyro and Accelerometer are pretty acceptable for VEX. The field isn’t really big enough (especially this year) to require something of a higher quality.
I would be careful when using DC to DC converters. We’ve had issues in the past with teams using the converters to “bump up” the voltage from the batteries to the cortex, which violates . Though, our team posted on the Starstruck Q/A whether or not we can use a converter to only power our Xbone camera.
We used a pixy camera last year to identify balls and create a self-aware autonomous. It was our first time using vision-tracking so it was pretty interesting. It didn’t score a single point in auton until the quarter and semi-finals.
Ik that this is an old thread, but I wanted to add my question here so as not to clutter the forum up. @pwnageNick How did you program that US Digital S4T Encoder on RobotC? Or did you use a different programming language?
