The inertial sensor malfunctions in the middle of the autonomous operation, causing the robot to spin around itself. This has been happening very frequently lately. How can I fix this?
Hi there,
In order to help you, you need to share your code with us so we can see the problem and hopefully correct it. Secondly, is your robot spinning anytime you have it turn using the inertial, or just at an random point in the autonomous?
-11865A
Have you tried switching the port and wire for the sensor? It could be that there isn’t a good interface between the inertial and the brain. It could able be that your inertial sensor in calibrating backwards so turning to 45 would read as 315. To fix this you could just switch out the sensor. If you’ve tried all of this can we see your code?
We had something similar during State and might have a cause.
The team would practice the auto run on the practice fields and then immediately go to the skills fields, only to find that the robot would spin out of control (they call it “break-dancing.”). This happened twice - worked fine on practice fields and break-dancing on the skills competition fields. The team noticed this discrepancy and asked me if I know how this could happen. I was at a loss.
After the qual matches were finished, I checked the various skills scores and found that no team had scored over 100 in autonomous runs. This was a strong field of teams with several that had previously scored much higher. I had the usual casual discussions with a few other coaches that I knew and mentioned this oddity. In general, the comments were made that the Gen 2 internal sensor was not great, etc. The team has been aware for years that the robot should not be touched during a calibration and had has code to start autonomous via touch sensor, followed by a 1 second pause before initial calibration.
I continued to be bugged by the break-dancing issue and the apparent difference between the practice fields and the skills competition fields. I then recalled seeing something from a previous Forum post that the Gen 2 internal sensor was extremely sensitive to vibration during calibration. I happened to be standing by one of the skills competition fields and noticed an extremely loud PA system playing music with a thumping bass sound. It occurred to me that this music had been playing pretty much all day long. The tournament was hosted in an older basketball arena at on top of a floating basketball court. You could feel the music thumping in your feet. It occurred to me that if my feet could feel the thumping, perhaps the accelerometer in the Gen 2 brain could feel it during calibration. I found that there was a pounding PA sub-woofer right next to the skills fields. I then walked over to the other side of the floor (a large NCAA arena floor) to the practice fields and found that these fields were located well away from any of the PA speakers. You could, of course, hear the loud music but I did not feel any vibration.
Could the pounding music impact the Gen 2 accelerometer during its calibration?
calibration is primarily for the gyro section of the IMU, we need to know the steady state output when the gyro is stationary. However, prior to calculating this value we wait until the accelerometer values are steady, this helps with not starting the actual calibration until the robot is not moving, so it’s possible the calibration code could be blocked if there are significant vibrations. I’m not sure if this type of vibration would impact the gyro.
It then would depend on how student code was setup whether you were blocked by calibration, VEXcode usually does calibration when the program is run and would block with a calibration message on the screen.
It’s no better or worse than any of our other products with IMU, they all use the same IMU sensor and similar code.
It’s human nature to blame external factors for our failures. As mentors, it is our job to redirect that internally - ask the students:
- How do you overcome that
- Is there a process (put robot down, turn it on, don’t move it, start the program, etc.) that leads to better results?
And so on
Thanks James. My very limited understanding is the gyro function is provided using MEMS based on a vibrating mass. I think you made a prior post about vibrations from the pneumatic pump stopping the inertial sensor from calibrating. In reference to other replies, the team understood the need to eliminate vibrations prior to calibration. Indeed, they had previously provided for turning on the pneumatic pump after calibrating. I’m not sure I understand your comment regarding being blocked by calibration and how student code might impact this.
VEXcode will do the drivetrain calibration when the program starts if you create a drivetrain object in graphical setup. Some students may call inertial.calibrate() again in their code, if they do not check calibration status (say just wait 2 seconds) it may not have finished but they may then move on and expect inertial heading to be valid and stable, which it will not be if still calibrating (ie. waiting for stable accelerometer values).
The IQ2 brain does do a calibration when it powers on, and it can also start one via the devices screen, that’s the place to look to see if external vibrations are causing issues.
Thanks for the info. Tournament is complete but we will try to simulate the noisy conditions.