Closed icemannie closed 3 years ago
Hello. That is neat. May I ask how you accessed the RomiGyro() Class in WPILib through the sim? I did not think it was implemented yet at all. I assume you have done this already, but I am curious what happens when you try Gyro.callibrate() or Gyro.reset() in your code? Obviously, the latter just recenters all values.
Gyro calibrate works. Gyro reset doesn’t work.
The Romi Gyro class is included in the Romi reference example now in the list available for use through VS Code.
On Thu, Jan 7, 2021 at 1:57 PM Mr. Roth-Ritchie notifications@github.com wrote:
Hello. That is neat. May I ask how you accessed the RomiGyro() Class in WPILib through the sim? I did not think it was implemented yet at all. I assume you have done this already, but I am curious what happens when you try Gyro.callibrate() or Gyro.reset() in your code? Obviously, the latter just recenters all values.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wpilibsuite/wpilib-ws-robot-romi/issues/78#issuecomment-756347676, or unsubscribe https://github.com/notifications/unsubscribe-auth/AESZCOSXFI2J7LSK44L6V63SYYG27ANCNFSM4VZNWVRA .
@MrRSquared: The kickoff release of WPILib (2021.1.2) has an updated Romi Reference example with the gyro and accelerometer built into the drivetrain
@icemannie: The offsets are supposed to be transparent to robot code (they are just used onboard the Pi while integrating the angular rates). The RomiGyro
reset should zero out the reported values (accessible via the getAngle[X/Y/Z]()
methods). There will still be some amount of drift (most gyros will do this), but one thing to try is to run the calilbration routine a bunch of times and see if the offsets vary wildly. They should be within 1-2 dps across calibration runs
Thank you both. I had not seen the code in the updated example. These robots are incredible.
The accelerometer reacts to romi motion. The imu rolls as shown in the video. SmartDashboard graphs show the X axis.
This is what gyro calibration console shows. [IMU] Beginning Gyro Calibration...
[IMU] Gyro Calibration Complete
[IMU] Zero Offset: {"x":-0.9625000000000001,"y":-9.835,"z":-5.005}
[IMU] Noise: {"x":-7.734999999999999,"y":1.8199999999999985,"z":0.34999999999999964}
This is what the documentation shows.
@icemannie I think you might want getAngleZ
, which is the angle around the Z-axis (vertical). I'll look into why the X-axis is so noisy
Thanks!
Y is very stable. Z drifts about 10 times Y then X is really poor.
What kind of filtering is being used?
Reset works.
Direction of yaw rotation is opposite to an FRC gyro. There turning to the right results in a positive angle increase. It does the opposite here currently.
More common terminology would be getYaw etc AngleZ is Yaw AngleY is Pitch Angle X is Roll.
Found a bug in the calibration routine :) A fix will be available shortly
Is the fix for all 3 axes?
I checked the imu axes again and all 3 are opposite in direction to the current robot usage. This is how I changed the Drivetrain subsystem for direction and terminology
public double getGyroRoll() { return -m_gyro.getAngleX(); } public double getGyroPitch() { return -m_gyro.getAngleY(); } public double getYaw() { return -m_gyro.getAngleZ(); }
The fix was for calibration (which was leading to excessive drift across all the axes)
This is now available in versions 1.0.4 and higher
Using the kickoff release of the Romi pi image, 1.03 web service package and the Romi reference example with the romi gyro added.
All 3 axes of the gyro run away. There is some response from turning the Romi but not close to actual angle turned.
The offsets from the Romi config page gyro calibration do not come through to the RomiGyro class.