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.
6 Likes
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
1 Like
That’s already included
(at least to change from a 50Hz to 100Hz rate)
5 Likes
James:
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.
Thanks!
2 Likes
https://api.vexcode.cloud/v5/html/classvex_1_1inertial_1_1gyro.html
https://api.vexcode.cloud/v5/html/classvex_1_1inertial.html
1 Like
This is an undocumented C API, not available through C++, I’d rather not release any of those details right now publicly. Inertial sensor is brand new, lets just start using it as delivered for now.
4 Likes
I think most users expect a level of consistency from the update rate of the system. Since almost everything else runs at 100hz, the IMU at 50hz is an outlier, which just leads to more confusion, especially when this isn’t officially documented. A lot of people are simply taught that the V5 system updates at 100hz, and so they should set loop times to 10ms. If you do this when your process variable only updates at 50hz, derivative measurements in your controller will be 0 every second sample, leading to undesirable behaviour. I personally know someone who was trying to write a PID controller for turning, who encountered this exact issue, as they had set their loop time to 10ms and as a result, the derivative term in their controller was hard to wrangle with. Setting their loop time to 20ms immediately resolved this issue. To me, this is a clear example of where the different update rates just cause confusion.
It’s not quite apples and oranges, nor is it concrete data, but through a lot of testing, both myself and others have found that with other sources for sampling yaw (i.e. 2 unpowered tracking wheels), a PID controller for point turning performs significantly better with a 100hz update rate than 50hz. Don’t get me wrong, you can get great results with 50hz, but tuning will be more finicky and final results will be worse.
Another point is for teams who want to implement odometry using the IMU data for heading and heading delta measurements for arc projections. Everyone who I’ve spoken to who have implemented odometry in vex can attest to the fact that fast update rates significantly affect accuracy. For a setup where you might use the IMU alongside integrated encoders or a single forward-facing tracking wheel, you have to slow down a 100hz update to 50hz so you can include the correct heading data.
Taking this a step further, I know people who have tried to implement sensor fusion, combining IMU data with left/right encoders to improve heading estimation, and perhaps even including accelerometer data for odometry. When using simpler algorithms, for example, a complementary filter, once again, you have to sacrifice the faster 100hz data from your encoders down to 50hz. Whilst more advanced estimators like a Kalman filter can allow for two separate sources updating at different rates, you still run into the issue that the V5 system doesn’t have any way of letting you know whether data from the IMU is fresh or not, so the best alternative is to run the IMU update step separately at 50hz. However, this data may or may not be 10ms old, and there is no easy way to account for this. Due to all of these issues, I know people who have decided to give up on projects for IMU + encoder sensor fusion.
Another problem with this inconsistency is that even with a simple setup, with a control loop running at 50hz, there is a 50% chance that your control loop may have an inadvertent 10ms added latency.
I hope this helps visualise the 2 scenarios that can’t easily be accounted for:
This means users who write their own controllers and state estimators have a harder time tuning and eventually achieve less consistent and accurate results.
All in all, unless there is a genuine technical reason why the IMU data cannot be updated at 100hz to userland, it is a no brainer not to do so in my opinion.
I know this is a long post for something that seems rather inconsequential or petty, especially considering I am not competing, but I spend a lot of my time trying to mentor and give help to people online (primarily in the unofficial vex discord) and this is just my feedback from those experiences, as well as previous personal testing.
15 Likes
By the way, that’s not even the worst case. The worst case would be to have, every 20 milliseconds, the motor update, then the user control loop update, then the IMU update, all in rapid succession (with the motors also updating 10 milliseconds later of course). This would mean a lag of just under 30 milliseconds from reading to motor command (20 between reading and control loop, and 10 between control loop and motor).
Open challenge to anyone reading this: assuming that the relative phase of the update loops (i.e. how in-sync they are) is completely random, what’s the probability distribution of the lag?
10 Likes
If the relative phase of the loops is random, then the probability distribution of the lag spans from 0ms to 30ms and is in the shape of an isosceles trapezoid with the upper base one-third the length of the lower base. (i.e. there is a 50% probability of a lag time between 10ms and 20ms)
This also means that there is only a 6.25% chance of a lag time greater than 25ms, as well as a 6.25% chance of a lag time less than 5ms.
This was a very intriguing and thought-provoking challenge, thank you for posting! 
9 Likes
The high update frequency is, probably, not necessary for good control of the vrc robots.
Due to the limited motor torque and, as a result, limited accelerations of the typical subsystems, there isn’t much unexpected that could happen in that extra 10-20ms if you model and estimate position and velocity of the subsystems in your code.
It is more important to properly timestamp each measurement when it is received from the sensor, than to have them available at high frequency.
Yes, if sensor measurements are available to user at higher frequency, you can write less sophisticated code that doesn’t have to deal with time stamps or precise modeling of the robot.
However, if you want to improve accuracy and precision further, you will need to use timestamps, filtering, and model some physics. Once you go that route, high frequency of the measurement update is no longer as important.
4 Likes
Any thoughts on creating a riser design for the vexiq field? Like a Murphy bed type design so we can store the field upright? And on lockable wheels? We have 2nd and 3rd graders and I’m not sure how they will be moving this new 6’x8’ board. Taking it apart and putting it back together each practice will take too much time and the field pieces can’t withstand that much stress on the connecting joints.
- Please don’t revive old threads
- This is best suited for its own topic
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.