juchong / adis16448-roborio-driver Goto Github PK
View Code? Open in Web Editor NEWADIS16448 IMU Library for FIRST Robotics and the RoboRIO designed for use with WPILib
License: Other
ADIS16448 IMU Library for FIRST Robotics and the RoboRIO designed for use with WPILib
License: Other
When trying to use the java library, it fails to initialize giving this error to the driver station ERROR 1 could not find ADIS16448
. I tried making it delay a bit before initializing it but it still doesn't work. The green light is on the unit and it appears to be connected.
Will this library be updated to work with the new 2017 wpilib?
I recall using this device years ago and manually having to put effort in to get this working. I'm Beta Testing the 2019 WPILib suites and associated FRC software. Specifically Java.
Step One I was hung up on. There is no repositories block in my "build.gradle". I added line for line from your sample:
repositories { mavenCentral() maven { url 'https://jitpack.io' } }
Step Two was fine only my dependencies looks like this:
dependencies { compile wpilib() compile javaVendorLibraries() nativeZip jniRoboRIOVendorLibraries() nativeDesktopZip jniDesktopVendorLibraries() testCompile 'junit:junit:4.12' compile 'com.github.juchong:ADIS16448-RoboRIO-Driver:master-SNAPSHOT' }
Step Three. I don't know what you want here so I created the file tree under "src" com\analog\adis16448\frc and placed the "ADIS16448_IMU.java" in it.
The import is Errored: [Java] The import com.analog can not be resolved
The Make a new instance of the driver is Errored: [Java] ADIS16448_IMU Can not be resoved to type
Trying to use the the Gryoscope fails to open it, returning 9 or 0 in the open function after running ReadRegistry for the product ID. I'm using the labview version of the example code. Do you think there's something wrong with the gyro, expansion board, or just RoboRio?
Hello, We are using this IMU on a RoboRIO with the 2019.1.0 update, and yet our IMU doesn't work.
I've tried to use a ADXRS450 Gyro on the same roboRIO and it worked. Please help.
java.io.IOException: opencv_java344 could not be loaded from path or an embedded resource.
I'm getting this error when I try to deploy the code to the RoboRIO, and from reading the other issues, this seems to be consistent with the errors in the 2019 build. The solution seems to be updating to the 2020 build, but how would I go about doing that?
Thank you in advance!
Our team is using lab view and have downloaded latest version and installed. When deploying code we occasionally get an error indicating that the ADIS library on the bot does not match the project. Is this a problem. Gyro seems to work ok.
Drift is an issue at times. If we power down and back up there is little drift. We have open set to calibrate on open. However after testing for a while and disabling and re enabling multiple times drift may be very large 0.25 degree to 0.5 degree per second.
Powering down seems to fix it for a while.
Using the 2020 WPI code for FRC in java the reset method is not setting the gyro angle back to 0.
Here is my code
private ADIS16448_IMU imu = new ADIS16448_IMU();
/**
/**
This runs after the mode specific periodic functions, but before
What's the possibility of extending this (awesome!) library to do integration from the accelerometers?
I know it might have some big error issues, but I thought I'd bring it up, as it's something our team would be interested in.
Within the scope of the project?
I could deploy code after removing the library and switching to the SPI gyro. I haven't tried more than the new ramsetecommand, which uses the wpilib Gyro class.
Saw only this in RIOlog:
java.io.IOException: opencv_java344 could not be loaded from path or an embedded resource.
attempted to load for platform /linux/athena/
at edu.wpi.first.wpiutil.RuntimeLoader.loadLibraryHashed(RuntimeLoader.java:125)
at edu.wpi.cscore.CameraServerJNI.(CameraServerJNI.java:40)
at edu.wpi.first.wpilibj.RobotBase.startRobot(RobotBase.java:213)
at frc.robot.Main.main(Main.java:27)
Not sure how it could relate to the ADIS16448 library, but haven't had the problem after removing it.
Running the simulator from vscode results in the following error:
Simulator GUI Initialized!
HAL Extensions: Successfully loaded extension
********** Robot program starting **********
Error at com.analog.adis16448.frc.ADIS16448_IMU.(ADIS16448_IMU.java:280): Unhandled exception instantiating robot com.analog.adis16448.frc.ADIS16448_IMU java.lang.NoSuchMethodError: 'void edu.wpi.first.wpilibj.SPI.free()'
at com.analog.adis16448.frc.ADIS16448_IMU.(ADIS16448_IMU.java:280)
at com.analog.adis16448.frc.ADIS16448_IMU.(ADIS16448_IMU.java:350)
at frc.robot.Robot.(Robot.java:30)
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)
Warning at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:244): Robots should not quit, but yours did!
Error at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:245): Could not instantiate robot com.analog.adis16448.frc.ADIS16448_IMU!
Just before we put our robot in the back we created a deploy for run on startup using labview and the driverstation messages indicated that the IMU16488 could not be found. We rebooted the robot several times and each time it could not be found.
When we use labview interactively, the IMU is found every time and works fine.
We tried the same on another bot and the IMU was found whether running interactively or running from startup.
Any experience with this. We're going to be a bit under the gun to troubleshoot this on inspection day.
I receive following from labview from Open vi.... I have latest copy as of Jan 15th. Kind of an odd error I would not expect. I don't think there is anything wrong with our code. Reads of the gyro seems to work. Error only occurs 1 time when code starts.
ERROR 1198 Invoke Node in ADIS16448_IMU.lvlib:ADI_IMU_ADIS16448_Open.vi:2260001->Drive Controller.vi->SubSystems.vi->Robot Main.viLabVIEW: (Hex 0x4AE) The VI is not in a state compatible with this operation. Change the execution mode of the referenced VI to reentrant for this operation.
After pulling my hair out for a few days I have decided to open an issue. We have the ADIS 16448 installed on the MXP port on the rio through a More Board. We are programming in labview and have updated to version 13 of the rio image. The gyro will drift enormously in a small amount of time, sometimes as much as a degree a second. However, other times the gyro will barely drift at all and act fine. Any help would be greatly appreciated, thank you in advance.
WPILib has published instructions for teams to set up CI builds using GitHub actions, but this requires linuxx86-64 binaries.
Currently the ADIS16448 dependency distributed at http://maven.highcurrent.io/vendordeps/ADIS16448.json only provides linuxathena (RoboRIO). Even a placeholder dependency to fix link errors but provide no utility would be great.
Example GitHub action error output:
> Task :linkFrcUserProgramLinuxx86-64DebugExecutable FAILED
/__w/2021-Swerve-Mech-Suit/2021-Swerve-Mech-Suit/build/objs/frcUserProgram/linuxx86-64/debug/frcUserProgramCpp/8i5onloyezpxocsi2iescoqww/DriveSubsystem.o: In function `DriveSubsystem::DriveSubsystem()':
/__w/2021-Swerve-Mech-Suit/2021-Swerve-Mech-Suit/src/main/cpp/subsystems/DriveSubsystem.cpp:32: undefined reference to `frc::ADIS16448_IMU::ADIS16448_IMU(frc::ADIS16448_IMU::IMUAxis, frc::SPI::Port, unsigned short)'
/__w/2021-Swerve-Mech-Suit/2021-Swerve-Mech-Suit/src/main/cpp/subsystems/DriveSubsystem.cpp:32: undefined reference to `frc::ADIS16448_IMU::~ADIS16448_IMU()'
/__w/2021-Swerve-Mech-Suit/2021-Swerve-Mech-Suit/build/objs/frcUserProgram/linuxx86-64/debug/frcUserProgramCpp/8i5onloyezpxocsi2iescoqww/DriveSubsystem.o: In function `DriveSubsystem::~DriveSubsystem()':
/__w/2021-Swerve-Mech-Suit/2021-Swerve-Mech-Suit/src/main/include/subsystems/DriveSubsystem.h:16: undefined reference to `frc::ADIS16448_IMU::~ADIS16448_IMU()'
collect2: error: ld returned 1 exit status
Example compatible vendordeps json entry:
"cppDependencies": [
{
"groupId": "edu.wpi.first.wpilibNewCommands",
"artifactId": "wpilibNewCommands-cpp",
"version": "wpilib",
"libName": "wpilibNewCommands",
"headerClassifier": "headers",
"sourcesClassifier": "sources",
"sharedLibrary": true,
"skipInvalidPlatforms": true,
"binaryPlatforms": [
"linuxathena",
"linuxraspbian",
"linuxaarch64bionic",
"windowsx86-64",
"windowsx86",
"linuxx86-64",
"osxx86-64"
]
}
]
Example incompatible vendordeps json entry:
"cppDependencies": [
{
"groupId": "com.github.juchong",
"artifactId": "adis16448-cpp",
"version": "2020.r3",
"libName": "libadis16448imu",
"headerClassifier": "headers",
"sharedLibrary": false,
"skipInvalidPlatforms": true,
"binaryPlatforms": [
"linuxathena"
]
}
]
I have tried to use this class with the 2017 control system, and I'm encountering an error that I'm not sure how to solve.
private static class InterruptSource extends DigitalSource {
public InterruptSource(int channel) {
initDigitalPort(channel, true);
}
}
This piece of code is throwing two errors in Eclipse: First it asks to implement several required methods from the interface. Easy enough, though I'm not sure what effect it would have on the code.
The second error is on the initDigitalPort(
function, which I assume sets the digital input for the interrupt and then enables it. This function seems to be missing from the 2017 WPIlibj implementation of DigitalSource
. Not only is it missing, but I can't seem to find any mention of any way to set the interrupt pin through DigitalSource
or any of its parent classes. I feel like this is an oversight, though it would be greatly appreciated if someone could point me in the right direction to fixing this.
My team and i have just set up out gyro and were messing with the smartdashboard, and as we deploy the code and enable our robot we get this error in the consol
so we checked the .h and it was fine but the ADIS16448_IMU.cpp in the src folder had 4 errors 2 being related to the the notify_all at line 239 and 328
the other 2 being related to line 368 where it says "wait" and line 961 where it says "ADIS16448_IMU::InitSendable"
does anyone else get these errors, if so how do we fix them because as of right now our gyro won't give us an angle.
Upon testing the sensor today, the gyro is working just fine and seems to be outputting the correct data. However, the accelerometer is not. Looking at all 3 axis, none of the accelerometers seem to be correctly reacting to our robot moving forward (I assume that the getAccelY() is in ms^2). I would guess that it is the Y axis that should be working, but it isn't. Additionally, the values of the accelerometer and constantly jumping around, they are never at 0.0 even when the robot is still but rather anywhere from 0.00-0.01. They never seem to exceed that upper bound even when the robot is moving.
this may be related to the post that balaji-venkatesh created on February 9 , but since that topic has been closed i was unsure if commenting on that would reopen it. We are having issues with the gyro returning 0 on any attempt to retrieve data. We have finished up our competition season and had some strange issues with the NAVX gyro, and wanted to see if the issue was present in the ADIS16448 device as well. However we are unable to get data from the ADIS gyro. We are using the MXP port and the device appears to properly connect (no error saying the robot cant find the gyro). All attempts to get angle data returns zero though. Our roborio is on the competition required v14 so i believe the MXP port issue should not be present anymore like on the 2019 release. we are using java and have attempted to use both V2 and V3 versions of the code release and have had no success. do you have any thoughts on what the issue might be?
The register read returns the product number correctly and the program indicates that the initialization was successful, but all the values read are zero.
We finally got the chance to use our ADIS16448 last night and we were seeing a constantish (always near it but it did "bounce around") 160 degrees on the yaw. The yaw delta did however respond to the robot turning except it only moved 45 degrees for every 90 that the robot turned.
After seeing this we then went back and tried a calibration which worked fine and then tried the above again with the same results.
Any tips on why this might be doing this? We are using LV if that matters with the same inputs to the open as the example.
Compared to the set of functions available on the Java driver's API (https://github.com/juchong/ADIS16448-RoboRIO-Driver/blob/master/java/src/main/java/com/analog/adis16448/frc/ADIS16448_IMU.java), the LabVIEW driver's API is missing instantaneous accelerometer values for X, Y, Z.
(I'm happy to look into adding these in a pull request).
I'm finding some issues between some of the VIs where they use an older non-type def control that are incompatible with other VIs.
For example, the Open and Refnum Set functions are incompatible.
Looks like you created type-defs after-the-fact and may have forgotten to update some or commit them to GitHub.
Thanks for supporting this driver. I note in the latest copy you've fixed the bug related to the reset and improved the AHR calc!
In the loop I note that on first pass of the WPI_IMP_loop.vi the deltaT is calculated by subtracting 0 from the timestamp from the Interrupt Wait vi. E.G. the shift register is initialized to 0. Could this cause a very large deltaT on first pass and introduce significant error in the accumulator. Instead of initializing to 0 should this be initialized to a timestamp so it will be in the same basis as the output of the Interrupt Wait VI?
Is it really appropriate to store a drift calibration and use it every time. The ADIS16448 seems to drift less than other chips that we've used but it still exhibits drift. I thought the purpose of calculating a new drift calibration every time the robots are rebooted is to get a current calibration. I believe that the factory calibrates each chip and stores that calibration on chip. Storing a drift calibration and using the same one seems the same as the factory calibration.
My impression was that these chips have a different calibration every time they are started up and that it changes with the temperature, amount of ferrous metal in the surrounding building, etc.
I'm aware that if you don't perform the new drift calibration provided, the driver will behave as before and perform a calibration every time it starts. We would not want to lose this capability.
On another topic. Our team did not use the HUD last year because we had some issues in getting it to work reliably; we only used the axis variable. If you defined another item for the AHRS Algorithm enum, it could be set to "No HUD" and disable the filter and save some processor time. The algorithms seem to be pretty math intensive. If performing vision, etc. processor time is valuable.
Jitpack has not produced a new snapshot since 2017.1.1, which is not compatible with the 'kickoff' release of GradleRio 2019.1.1 due to conflicts with OpenCV versions. Using Jitpack snapshots as described in the README will successfully compile, but will fail to run on the RoboRIO due to a missing opencv_java320 native dependency (the kickoff release moved to OpenCV 3.4.4.)
Jitpack snapshots are failing due to problems in the C++ build. There is a problem in the build.gradle file (addressed by PR #28 but the overall build structure needs further work before it will compile on Jitpack. C++ builds with GradleRIO now require the 'installRoboRioToolchain' task to be run before the build.
I don't think I will have time to tackle the C++ build issues myself this season, so I am submitting this as a warning to other FRC teams until someone else can pick it up. Team 568 only uses the Java library, so for now we've created our own Java-only fork. You can add this to your builds by replacing the dependency line in this project's README with:
compile 'com.github.FRC-568:ADIS16448-RoboRIO-Driver:java-SNAPSHOT'
Hi, the 2022 release of WPILib uses Gradle 7 which doesn't allow http based Maven repos. Is there a way you could use a repository that supports https, or enable https on maven.highcurrent.io? It has a certificate but it's self-signed.
Thanks,
Sean
Hello!
I'm trying to use this IMU code for the 2018 RoboRIO / WPILib, but it seems to depend on wpilibJavaJNI
which no longer exists on the 2018 robot and causes the robot code to crash on startup. Is there any way to update this for the 2018 release of wpilib? If it makes a difference, I'm using JitPack as a maven repo for this.
Thanks!
Here is the full trace:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no wpilibJavaJNI in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at edu.wpi.first.wpilibj.hal.JNIWrapper.<clinit>(JNIWrapper.java:22)
at edu.wpi.first.wpilibj.RobotBase.initializeHardwareConfiguration(RobotBase.java:171)
at edu.wpi.first.wpilibj.RobotBase.main(RobotBase.java:194)
we are having an issue where the ADIS16448 is apparently being found on the roborio (at least there is no gyro not found error), but no data is actually being sent or collected by the gyro. any command to get angle x, y, z, or acceleration results in 0.0. is seems like after several hours of re-seating the ADIS16448, swapping to a different ADIS16448, rebooting the robot, and resetting the code fixes the issue, but there is a chance that every time the robot is re powered the gyro once again does not collect and send any data. do you have any clue as to what might be happening here?
In the Java (https://github.com/juchong/ADIS16448-RoboRIO-Driver/blob/master/Java/com/analog/adis16448/frc/ADIS16448_IMU.java) and C++ (https://github.com/juchong/ADIS16448-RoboRIO-Driver/blob/master/C%2B%2B/src/ADIS16448_IMU.cpp) sources, the header seems to state that the project should be under BSD. However, there is also a license file in the root folder (https://github.com/juchong/ADIS16448-RoboRIO-Driver/blob/master/LICENSE) which is GPLv2.
Did you mean to have the project under GPL, or should it be BSD? Also, where is the origin of the C++ and Java sources?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.