We messed around with the new V5 Inertial sensor and completed our turning code. Here’s a little peek at our turning testing: VRC Tower Takeover V5 Inertial Sensor Turning [1080P] - YouTube. As far as we can tell, the sensor seems to be a solid upgrade over the gyro. We made a custom PID function and used that in the video but we’ll test the sensor with both the stock PID and the custom one when we have access to a field. Nice work with this sensor Vex 
13 Likes
Apart from qualitative results shown, what quantitative results do you have, and test procedures to reproduce results.
Two 90-ish degree turns on a video do not make good engineering 
7 Likes
I’m not sure what kind of test procedure you are talking about to replicate this, but if it is showing behind the scenes code, I don’t think my team would appreciate leaking the code this early. This post is not intended to be some sort of science fair presentation; it is an overall first impression of the sensor and sneak peek at our progress since it just got out. This post is like something you would find on Amazon, a buyer’s review of a product, not a full on demonstration or analysis of the the sensor.
7 Likes
The title of the thread is miss leading. “Testing” implies actual procedures and “Results” implies something measurable and reproducible. Look this forum is for sharing ideas - if your team is not ready to do so, then it may be best not to post vague information. Be precise and analytic, that would be most helpful.
13 Likes
Does anyone know the initialization time necessary for the sensor?
The recommended time is 2000ms
Are there any improvements in performance or accuracy in comparison to the old accelerometer and gyroscope?
We noticed significantly less drift compared to the gyro. Oddly enough, when calibrating the sensor through the default time calibration the sensor would start at .38-.40 degrees and shift between those numbers while motionless. The Inertial.rotation(rotationUnits::deg) command returns degrees in the accuracy of the hundredths place; however, it still shifts slightly about .02 up and down but does not go completely going haywire like the previous gyro did, which started counting up or down indefinitely drifting away from the actual angle. While testing 90 degree turns, the return value did seem to correlate with the real world angle, implying that the is little to no need for scaling the inertial sensor. I cannot speak to the improvements in the accelerometer, however, because we never had the old version to compare it to.
4 Likes
if possible could you also put up more videos of it working and different applications of the accelerometer?
Please and Thankyou
4 Likes
Yes, I plan on testing further once I can get my hands on the bot.
2 Likes
I went further with testing, tried the following scenario as well:
- Reset angle.
- Lift the robot (with IMU fixed to the robot, obviously)
- Tilt the robot backwards 90 deg (yes, put it on the back)
- Rotate robot 90deg left
- Tilt the robot forward 90deg (so it is wheels down again).
- Check the angle (reads about 90deg)
- Rotate robot 90deg right (i.e. return to the initial heading)
- Check the angle (reads close to 0deg)
I was honestly impressed how well the IMU handled this scenario. During the step 4, when the gyro was rotating over axe other than the original ‘z’, the heading was updating as if everything was normal.
8 Likes
That sounds like a pretty solid test, nice! Can you specify what you mean by close to 0 degrees? Was it reading 0.1 degrees or like 1 degree?
Our students tested the inertial sensor before they left for Christmas Break. Based on their results was definitely a ‘solid upgrade’ from the older gyro sensor.
They ran a simple test, 10 separate times. From a resting position they had their robot perform a 360 degree turn. It was just short of the 360 degrees, but consistently so. The variance in the final position of the robot was minor in each test.
In the past, the same test on the older gyro sensor had horrible results. The variance in the final position was all over the place.
I’m thankful that the primary outcome of the test is students now have a gyro sensor they trust. This wasn’t the case in the older version.
13 Likes
Well, I haven’t had a real hard stop reference. My goal wasn’t to validate the precision or reproducibility, but rather to validate the behavior under significant pitch (such as when the robot accelerate or decelerate too aggresivly)
4 Likes
Just did more testing yesterday and the video of the tests will be uploaded soon. I can say pretty confidently that the inertial sensor will not drift like the previous gyro after a series of random jerks. Also, we just compared the stock turnFor method provided by the smartdrive class and our custom PID turnFor method and found that the stock method’s 90° turn was not actually 90°. It overshot the target every time it was tested. Either the inertial sensor started malfunctioning or the function is inaccurate. According to the results of my tests, I highly doubt that it’s the former. It may important to mention that all of this testing took place on carpet and not on an actual field so the surface friction may affect the tests.
4 Likes
The turnFor function in the smartdrive class is very simple, no PID or anything is used, all it does is slow down as the turn is getting close to the target and then stop when the error is less than 2 degrees. We may improve a little for a future release but we really want teams to write their own code for this and not rely on VEX providing everything for them, it already does more than some of the dev team would like.
15 Likes
and there are simple fixes teams can do to correct minor errors. For a lot of teams keep it simple, and when ready dig deep and do better.
2 Likes
One approach to having teams extend functionality provided by the drivetrain/smartdrive classes would be for the team to write a class that inherits from drivetrain/smartdrive. However, with the drivetrain class marking the motor_group as private, this is difficult to achieve.
Similarly, for teams that would want to extend drivetrain/smartdrive to support Mecanum/X-Drive, it might be beneficial to expose getter methods on motor_groups that would allow one to access each motor in the group.
3 Likes
I can look into doing that.
Obviously the motor groups (or motors) are passed to the drivetrain when it is created, so technically you would already have access to them, but I can move them to be protected or public. The smartdrive class inherits from drivetrain but never needed direct access to the motor groups. There will be an update to these classes in the next VEXcode anyway as we recently found a couple of bugs.
All three of these classes just call into existing C++ functionality we have, they never need access to the underlying C API in the SDK that gives access to the devices on the V5 brain. So technically someone could easily create better and open source versions of them.
6 Likes