I have a couple of questions regarding the inertial sensor and its reliability:
Sometimes the inertial sensor just misses the target I have set for it by around 10-15 degrees however if you run the code again it normally works perfectly fine. So is this a calibration issue? The inertial sensor is normally close to the target which makes me think it isn’t a complete malfunction but it is still generally a noticeable amount off from where it should be (I code with EZ-Template if that has anything to do with it).
After the 15 second autonomous and the remaining 1:45 of the match how off will the inertial sensor be? Is it possible to get the values during driver and have them still be accurate enough (within 1 degree) for use?
Should harsh turns affect the sensor and if so how do we combat this? We tested this a while back and after doing around 5 turns at full speed the sensor was about 30 degrees off. We tested this with a different sensor and it was much closer to being accurate after the same 5 turns (I think less than 10 degrees off). Is this a sign that the whole sensor is faulty and should these movements interfere with the sensor’s accuracy at all?
No, the inertial sensor can be anywhere on the robot.
To answer OP’s questions: #1, could be a bad sensor, try the same actions with a replacement if possible. Also look into tuning your PIDs. #2, what are you planning to use the inertial for in driver control? #3, same as #1. Again look into tuning your PIDs.
The placement of the Inertial Sensor is very important to its accurate readings. As previously mentioned, it is essential to align the Inertial Sensor along the axis the robot will be experiencing a change in motion. This alignment determines how the sensor produces measurements in reference to the spatial orientation of the robot. These measurements allow the user program to change the robot’s behavior.
Basically just mount it to the drivetrain and not something that can move like an arm.
There might be an isolated case where an Inertial Sensor will be placed on a robot’s external component, but for most applications, the sensor will be placed on the drivetrain’s chassis.
Specifically for question 3 it was very low tech as we lined our robot up with the long goal (we have an aligner) recalibrated the sensor drove forward spun around a few times and then realigned ourselves with the goal.
We tried multiple sensors and the second sensor was much more accurate but it still wasn’t perfect especially after the spinning (being about 10 degrees off)
Mount the gyro in/on something that will absorb high frequency vibrations.
The vex Gyro is quite sensitive to vibrations. My team found last year that our gyro drifted a degree or two per second when we spun the intake. This drifting from the intake vibration could be bypassed by sandwiching the sensor in an anti-slip mat.
————————————————————————————————————————— Calibrate the Gyro
The vex gyro’s don’t seem to know how many degrees are in a full rotation. But here’s the fix:
Rotate the robot multiple times. (Keep track of exactly how many rotations you perform — I do 20 rotations)
Perform the calculation needed to scale the gyro’s raw readings into proper 360° per rotation space.
scalar = (360 * true no. of rotations) / measured rotation in degrees
for example:
scalar = (360° * 20 rotations ) / 7120 = 1.01123596
Correct the raw reading by scaling it using the scalar you calculate.
I write a function that gets the raw reading, scales it, then wraps it to a value between 0 and 360° for ease of use(note wrap_to_360 is a custom function I wrote):
That would work. You could convert the raw gyro reading to the proper heading and then set the EZ-Template chassis object to the corrected heading. You could potentially run this in a background task. Using the function I made the background task would look like:
pros::Task update_gyro([&] {
pros::delay(3000); // wait for gyro to calibrate
while (true) {
chassis.setOdomTheta(get_heading());
pros::delay(100); // update every 100ms
}
});
I’m not sure if this is the best method. It depends on how EZ-Template handles setOdomTheta(). It is possible that setting theta may cause ∆theta in the odometry math to be unexpectedly large at that time step, causing slight inaccuracy in the odometry calculations. This affect could be minimized by decreasing the delay in the task loop to 10ms.