Honestly same, I’m afraid my bot is gonna tip
Any evidence for 10ms sample rate?
The V5 port message rate is not fixed, different can (and do) use different rates. For example the ADI port (legacy A-H, which is implemented as another, internally-wired V5 device) initially used to sample at 20Hz (every 50ms), which made it quite unusable with the legacy gyro (this was before VEX actually implemented direct gyro support into the ADI MCU). VEX then switched to 200Hz (5ms), which is the current rate for ADI and which is good enough to actually roll your own gyro support, only using ADI as an analog frontend. With precision matching and exceeding that of the ADI MCU built-in solution when using the RTOS nature of PROS properly.
The V5 architecture has enough OOMPH to support even a 1kHz message rate, possibly on each port (keep in mind that each port is internally a fully independent HW state machine with dedicated chunk of on-chip tightly coupled memory in the FPGA).
Looking forward to playing with the new gyro (My RS485 sniffer is ready)!
Well, the rules say any part on the vex EDR website, so I’d assume it would be.
No assumptions needed…looking at the game manual (https://content.vexrobotics.com/docs/vrc-tower-takeover/GameManual-20190816.pdf), R14 on page 27 is very specific regarding the legality of new products.
I’m sure I’ll be corrected if I’m wrong, but the theoretical max message rate is still bottlenecked by the fixed rate at which vexos running on CPU 0 copies new data into the shared buffer with CPU 1 (which happens basically every 10ms)
To my knowledge this has remained unchanged (and applies to anything on the smart port “bus”) since James posted this
raw message rate for the inertial sensor is 50Hz. Three wire port (ADI) is 100Hz. Motor is 200Hz, but data is still only available to user code at 100Hz as explained by @hotel.
I’m very skeptical about the double integration being able to reproduce accurate results, but will be happy if someone can prove me wrong.
I figured it was legal, but wanted to ask the question openly for clarity.
The big question is when will the 3 wire port expander finally be available. 8 ports is not nearly enough for robots that use a lot of sensors. Even worse when pneumatics are involved.
An expander “should” be straightforward and I understood that it was almost ready quite a long time ago.
That’s an absolute dreeeaaam. Using tracking wheels, I only have 2 ports left for v4 sensors
Vex really pulled through with that shipping! Got ours today!
I’m trying to get mine, but between four teams in our school, school funding, winter break, etc. probably not going to get it til January. Glad the VexCode API got updated though. I was really annoyed the last couple days when I could not read through everything in the inertial class.
Thanks for the details.
Is ADI really 100Hz? When I was experimenting with that, I remember getting new numbers every 5ms, not 10. I guess I need to redo the test. (Human memory, pffff)
Is the chip inside the IMU itself limited to 50Hz, or is that an arbitrary firmware decision? (It might be plenty enough, but we still run the custom straight drive PID at 100Hz I think)
As for the double-integration, the biggest issue is that in this universe, you can recognize any (local) rotation from no rotation (i.e. you can measure, to some precision, absolute rate of rotation) but there is no way to recognize no motion from constant-speed straight-line motion. The double-integration error accumulation just emphasizes that.
yes, message rate is every 10mS, however, digital input changes can also cause a message to be sent so that can theoretically run faster.
we currently run the internal chip at 200Hz and calculate the quaternion value at that rate., roll, pitch and yaw are derived from the quaternion in the brain. It was my (somewhat arbitrary) decision to use a message rate of 50Hz in this first release.
Is there a chance the external message rate will be increased to 100 or 200 Hz in a firmware upgrade, or is there a hardware limitation?
The inertial sensor looks epic! I can’t wait to get one!!
There’s no reason we can’t increase to 100Hz, going beyond that may not be beneficial as many other parts of the user code side of vexos run at a maximum of 100Hz, so all we would be doing is skipping some messages. Having said that, if anyone can make a good case with code and/or data to backup the claims, we will always consider trying to make improvements.
Would it be at all possible to have this as a user changeable “experimental” setting? Something that is disabled by default but those who want to experiment then have that choice
That’s already included
(at least to change from a 50Hz to 100Hz rate)
Now you tell us… How is that changed? Also, is there any API documentation for the VEXcode C++ functions on this device?
If user functions generally update at 100 Hz, then I agree that 200 Hz probably isn’t worth the effort for you to add.