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.