juchong / adis16470-roborio-driver Goto Github PK

Are there plans to support simulation? It should be pretty straightforward to add a SimDevice.

For example:

• https://github.com/wpilibsuite/allwpilib/blob/master/wpilibc/src/main/native/cpp/ADXL345_SPI.cpp#L22
• https://github.com/wpilibsuite/allwpilib/blob/master/wpilibc/src/main/native/cpp/ADXL345_SPI.cpp#L64

We loaded the new release yesterday and it did not solve the startup problem. Every time we power up, we have to then reboot the roboRio before the gyro will start. Values returned are 0.0 until we reboot.

The problem seems a bit worse than before. Previously, when we deployed our Java code the gyro would start up every time after we deployed. Now, occasionally it does not start after deploying code which of course restarts the software.

It appears that WPIlib 2022 (beta) requires HTTPS for vendor libraries, and that's preventing installation:

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':linkFrcUserProgramDebugExecutable'.
> Could not resolve all dependencies for configuration ':opencv_shared_linuxathenadebug'.
   > Using insecure protocols with repositories, without explicit opt-in, is unsupported. Switch Maven repository 'WPI6606dc7e-fb96-436f-a804-c07a5d841a14_0Release(http://maven.highcurrent.io/maven)' to redirect to a secure protocol (like HTTPS) or allow insecure protocols. See https://docs.gradle.org/7.1.1/dsl/org.gradle.api.artifacts.repositories.UrlArtifactRepository.html#org.gradle.api.artifacts.repositories.UrlArtifactRepository:allowInsecureProtocol for more details. 

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 571ms
The terminal process "bash '-c', './gradlew build generateVsCodeConfig   -Dorg.gradle.java.home="/home/dereck/wpilib/2022/jdk"'" terminated with exit code: 1.

Terminal will be reused by tasks, press any key to close it.

When we power our robot up, the gyro does not start. Messages are sent to the driver's station indicating that the calibration is in progress and then another indicating that calibration completed successfully. However, all values read from the gyro remain at exactly 0.

When we reboot the roborio from the driver's station, the gyro calibrates and starts up normally.

Your r2 release did not include the following file. Please add ASAP. We're urgently awaiting this as we have our first competition next week and we have to reboot our robot every time after we power up to get our gyro to work.

ADIS16470-RoboRIO-Driver_2020.r2zip

Our team measures from 7 to 8.5 degrees of drift in 2.5 minutes. This seems high as compared to the spec on the chip. We tried multiple calibration times up to 16 sec with similar results. We ran this test on two separate chips on two different dev boards. Boards were perfectly still during calibration.

What is a reasonable drift for the driver with this chip. How much drift did you see when testing your calibration method.

Our team uses Java.

Here's a possible fix for the drift issue with the driver. You suggested increasing the calibration time and that really doesn't have any effect. The drift is far above the spec and makes the chip almost unusable.

First, let's assume that the chip and its firmware are good. Then the problem has to be in the driver. Our team wrote our own calibration that runs after the chips calibration which yielded surprisingly good results. Our drifts with this change are in the 0.1 to 0.3 deg in 2.5 minutes (FRC match time) which is great. The drift is amazingly consistent and looks like your integrator is adding up a constant error over time. We also record the complimentary values at end of our calibration and tare them off.

I've read through your code and you are using the following constant in your integration:

// Static Constants
private static final double delta_angle_sf = 2160.0 / 2147483648.0;

Your integration looks like this.
// Scale sensor data
delta_angle = (toInt(buffer[i + 3], buffer[i + 4], buffer[i + 5], buffer[i + 6]) * delta_angle_sf) / (500.0 / (buffer[i] - previous_timestamp));

m_integ_angle += delta_angle;

You return the following:

public synchronized double getAngle() {
return m_integ_angle;
}

If your scale factor

delta_angle_sf/500 is wrong by even a small amount, you are integrating error every time you take a sample. I'm not sure where the delta_angle_sf comes from... it looks kind of magic. I suppose there could even be round off error created there that's integrated.

What if rather than integrating this constant every scan, you just multiply the return value by it. That way you don't integrate any error in the factor (I suppose that first I'd also verify that this number is correct).

Consider trying:

      delta_angle = (toInt(buffer[i + 3], buffer[i + 4], buffer[i + 5], buffer[i + 6])  * (buffer[i] - previous_timestamp));

public synchronized double getAngle() {
return m_integ_angle * delta_angle_sf / 500;
}

This change only integrates the values read from the chip. Assuming they are correct, this has potential to remove at least some of the drift.

I suppose the other source of error could be if the timestamps are wrong but you seem to be getting those from the chip?

We also saw that the gyro reset function does not reset the complimentary x and y axis to 0 properly. We're always seeing 1 to 3 degrees of offset after calibration. We have just been storing that with our own calibration routine and taring it off. This works well for us.

Consider modifying your reset routine to the following:

public void reset() {
synchronized (this) {
m_integ_angle = 0.0;
compAngleX = 0;
compAngleY = 0;
}
}

Note that for this to work... compAngleX and compAngleY must be made fields in order to reset them. There's no way to reset them from outside your acquire method.

Our team would still prefer to have an X and Y angle that does not have the sensor fusion. I appreciate that it is cool, academically interesting, etc. but on a robot it's not reliably usable due to vibration issues from mechanisms like shooters or proximity to motors that create magnetic fields. Z axis do not seem to be adversely affected by vibration.

We can use the complimentary values at the end of the game for climbing because we do not use our shooter at that time. However, during the autonomous portion of the game, we will not be able to use them to detect when our bot is on top of a ball and provide a safety stop.

You've provided a complimentary filter for the X and Y axis angles. I've not been able to find a method to read the X and Y angles in a similar way to the Z angle which is integrated.

The Z angle provides a very reliable reading that is repeatable and consistent.

The X and Y complimentary values seem to be ok until we run our shooter. Perhaps it's vibration but these values rapidly increase from near 0 to 12+ degrees in just a few seconds when we start our shooter. When we stop the shooter it coasts down and the X/Y values ramp back to near 0.

The Z axis or getAngle() value remains relatively constant around zero when running our shooter.

The X/Y axis measurement is critical for things like climbing level or determining when your bot is on top of a ball in autonomous.

Could you add an X and Y totalized angle without the complimentary filter?

We encountered a number of issues when configuring our ADIS 16470. We used roborio image 2019 v14, and WPILib 2019.4.1. We used the sample java code, and a few issues came out: the data light is never on, even after calibration; the checksum is incorrect (invalid, does not match); dt drops to 0 after spewing out valid data for a few seconds (when we made the checksum condition always true, such that it will always output regardless of checksum validity).
Chief Delphi Question Link
-- Team 6866

********** Robot program starting **********
Error at com.analog.adis16470.frc.ADIS16470_IMU.(ADIS16470_IMU.java:248): Unhandled exception instantiating robot edu.wpi.first.wpilibj.SensorUtil java.lang.IndexOutOfBoundsException: Requested DIO channel is out of range. Minimum: 0, Maximum: 26, Requested: 27
at edu.wpi.first.wpilibj.SensorUtil.checkDigitalChannel(SensorUtil.java:104)
at edu.wpi.first.wpilibj.DigitalOutput.(DigitalOutput.java:36)
at com.analog.adis16470.frc.ADIS16470_IMU.(ADIS16470_IMU.java:248)
at com.analog.adis16470.frc.ADIS16470_IMU.(ADIS16470_IMU.java:230)
at frc.robot.Robot.(Robot.java:32)
at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:231)
at edu.wpi.first.wpilibj.RobotBase.lambda$startRobot$0(RobotBase.java:329)
at java.base/java.lang.Thread.run(Thread.java:834)

There are no binaries for linux desktop which means this device can not run in the simulator on linux.

> Task :linkFrcUserProgramLinuxx86-64DebugExecutable
/usr/bin/ld: /home/dereck/frc/SimDemo/build/objs/frcUserProgram/linuxx86-64/debug/frcUserProgramCpp/9760xtgdau9jsoxxi90ozrpww/Robot.o: in function `Drivetrain::Drivetrain()'
/home/dereck/frc/SimDemo/src/main/include/Drivetrain.h:38: undefined reference to `frc::ADIS16470_IMU::ADIS16470_IMU()'
/usr/bin/ld: /home/dereck/frc/SimDemo/src/main/include/Drivetrain.h:38: undefined reference to `frc::ADIS16470_IMU::~ADIS16470_IMU()'
/usr/bin/ld: /home/dereck/frc/SimDemo/build/objs/frcUserProgram/linuxx86-64/debug/frcUserProgramCpp/9760xtgdau9jsoxxi90ozrpww/Robot.o: in function `Drivetrain::~Drivetrain()':
/home/dereck/frc/SimDemo/src/main/include/Drivetrain.h:36: undefined reference to `frc::ADIS16470_IMU::~ADIS16470_IMU()'
collect2: error: ld returned 1 exit status