In simple terms, after giving it a bit of thought I think if you are having a continuous while loop you can do the following:
int vel = 0;
int pos = 0;
while(1==1){
vel += accelerationFromSensor;
pos += vel;
vex::task::sleep(10);
}
This should work for one dimensional velocity, but if we extrapolate this for 3 axis’ and include trigonometry we can do odometry with just the one sensor. Now will it be accurate? Probably not. Now will it be precise? Probably not
But we can likely improve the accuracy and precision a bit by using the robot’s internal clock as well, but it still won’t be that big of a difference.
Sorry to “revive” the whole displacement from acceleration debate, but after some thought, couldn’t you use basic kinematics equations and then calculate displacement based off of that. I mean yes all values would have to be updated a lot, but for those who understand the os a little better, is it feasible to use kinematics equations to find displacement given time, acceleration, and velocity (which would start at 0 and depending on acceleration, would change based on other kinematics equations (most likely v^2 = v(initial)^2 + 2a(delta(x)))?
The basic kinematics equations you speak of are directly derived from the calculus formulas, with the assumption of constant acceleration.
If you work out the math, you will find that integration by Riemann sums is exactly the same as the approach you describe. Unfortunately, that also means your approach has exactly the same pitfalls (namely, far too much error to be useful).
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)!
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.
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.
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.
