Has anybody heard if the new sensors for V5 are coming anytime soon?
When V5 was first made public, there was reference to additional sensors that were being developed (original article).
I am particularly interested in the new Gyro/Accelerometer. I was planning on finally getting a set of gyros for my classes/teams, but am worried that a new sensor will immediately out-date them.
Not sure about the new sensors.
Vex has made a lot of promises they have not kept.
However, I would probably save your money in regards to buying the old gyros.
They are not very good quality, and V5 does not support it as well.
It is worse on V5 than it is with cortex.
Even with cortex, people had to work hard to minimize noise, drift, and inaccurate readings.
I’d be happy with just the 3-wire expander so we aren’t so constrained with the existing sensors. IO is one area where Cortex is >> V5 currently.
VEX. If anyone on the VEX tech team is reading this, you would make my entire season wonderful if you give us something to use more 3-wire sensors. Thank you sooooooo much!
Yeah a new gyro sounds nice but what about the LiDAR. Imagine actually being able to have the robot see around the field more than just with the vision sensor.
The worst part is that they made the V5 brain with only a few (8?) three wire ports and 21 whopping smart ports. There are a lot of three wire sensors but only 3 things (Motor, Radio, and Vision Sensor) use the smart ports and you can only have 8 motors on a competition robot. I would love for Vex to make some more smart sensors, even if they were mostly the same as the Cortex ones. It would maybe make them more reliable for V5.
Agreed. LiDAR would be an absolute game changer for autonomous, especially in a game like TT where the field consists of relatively simple game objects
I always thought having Prox sensors would be amazing.
Especially with options like these:
Or lets just take it a step further and allow V5 to talk to third part sensors… I do understand issues with Europe using PNP and America mostly NPN, but teams should be able to over come that. I probably should invest in Turck for how much we use it at work…They make really great sensors.
The old Vex Gyroscopes are compatible with V5, just use a 3 wire cable. I can’t deny that they have a lot of drift and inaccuracies, but there are teams that have managed to use them (using V5 or Cortex)
If you’re using PROS for V5, it has software to help limit Gyro drift built in. If you’re not using PROS, I would not recommend using a gyro
I’m no electrical engineer, but designing a gyro(IMU, not MEMS) to work doesn’t seem all that hard. Most IMUs use SPI or I2C, so you would just need to put a microcontroller in the gyro to convert and read values on RS485. Easier said than done, yes.
Lidar almost seems easier.
I know that V5 technically supports the gyro, and that some teams are able to use it.
However, it is worse with V5 than cortex, which is why I said there was limited support.
Nope actually. While this was true for cortex, this does not apply to V5.
Back on cortex, the gyro integrator was handled by the user code. If you wanted, you could code your own integrator (as pros did) because the user refresh rates on cortex were reasonable. This is why PROS and QCC2 was able to make their own integrator better than robotC.
However, things are different with V5. With V5, the integrator actually runs in vexOS on the cpu that handles the legacy ports. This integrator gets ~1ms refresh rate because it is run directly on the legacy port cpu. However, I have been told that integrator is pretty terrible.
Unfortenately, that integrator is not customizable or replaceable by the user. And it is impractical to try to provide your own integrator in your code, because in V5, the legacy port refresh rate available to the use is much less than cortex.
I might be wrong, but I think the V5 legacy refresh rates are ~10-20ms, which by many accounts is much too slow for integration.
There is nothing PROS or anyone else can do to improve the gyro integration, since it is VEXos that manages the gyro. The only way to improve that integration would be with a firmware upgrade from VEX, but I find it most likely they would rather release the new gyro than improve the old.
Maybe the VEXos integrator works fine, or people have managed use a custom integrator with that limited refresh rate, but it will be worse than cortex. For V5, my opinion is that encoders are much better for turning.
Thanks for the input.
I’ve been using V2 hardware (Cortex) for the past 8 years but with BEST robotics and in an introductory engineering class. We’ve used encoders but have no experience with gyros or accelerometers. We just started a few VEX teams this past January and were hoping to explore options other than encoders next year. I may purchase a set, but after reading through this post, I will hold off on purchasing more until the next generation that uses the smart ports is available.
Based on my reading of the System Architecture page, the internal Cortex M0 processor which controls the ADI ports sends live values up to the main processor every 5 ms. The equivalent value for an old Cortex M3 is dependent on user software, but in most cases, it ranged from about 5ms to 20ms.
That would probably be wise. However, seeing as they did not do a product reveal at VEX Worlds this year, I would imagine it may be some time before they release any sensors which utilize the Smart Ports (aside from the Vision Sensor, of course)
For many competition purposes, just encoders, potentiometers, and limit switches can serve most roles. Maybe look into more advanced uses of these sensors, such as 5225A’s odometry system?
Not sure I agree with that, it should be marginally better.
Unless there’s proof of the same gyro on the same robot showing worse performance with only a control system swap, I don’t think you could say it’s worse.
The update rate is currently 10mS, that’s something that is controlled by vexos. Limit/touch switches will report the change when they are pressed or released to remove some of the latency.
Yeah, thats reasonable. I have not done that testing.
However, I still think the cortex PROS integrator > robotC integrator, the latter of which I think is comparable to the VEXos integrator.
VEXos might be marginally better than robotC, but is it better than PROS or QCC2?
My post was intended to show that there can’t be any advantage to using PROS, and that a custom integrator is potentially impractical.
I have talked to a few people who believe the VEXos integrator is worse than cortex, and were asking me about using the PROS integrator or QCC2, which I answered with this response that the user refresh is probably not enough, and that the built-in integrator is locked-down by VEXos.
I don’t believe slow user refresh rate will prevent you from getting accurate results from a custom estimator. Thermal drift and mechanical vibration of the gyro are, probably, going to contribute most of the error to the position (angle) estimate.
Depending on the electrical, thermal, and mechanical noise levels you may need to throw out large percentage of the observations. However, good estimator does more than a simple integrator.
Large robot is not going to wildly accelerate or decelerate over a 10ms interval. If you correctly model robot rotation as a function of current angular velocity and acceleration due to the its own motor power and possible interaction with external objects, then it shouldn’t be that hard to filter out any out-of-range gyro measurements.
Accurate knowledge of the measurement latency, is probably, more important than the refresh rate of the sensor.
It would be great if we could know even approximately delays involved in getting analog measurements on V5, similar to how these threads go into details of Cortex hardware timings:
It’s hard to say, again, a direct comparison with the only variable being the algorithm used would be the only way to know. The algorithm in V5 is not exactly the same as ROBOTC, I tweaked it a little. The AD conversion in the V5 is also a bit different in that we over sample, usually around 20 raw readings are averaged before being used by the integrator (ie. we can take around 20 samples of the input every 1mS).