I will definitely update with full stack trace once I get access to our D.S. but I was just wondering if anyone has some answers without seeing the logs. Our gyro(the ADIS16470) threw a full buffer and thread exception whenever we connected to FMS. It works fine when we are not connected to the field but when we connect to the field the transition from auto to teleop causes this issue and breaks our robot code. My best guess as to why this may be happening is because I wrote a wrapper class that runs paths at 200hz(maybe that was a bad idea I heard 200hz somewhere and ran with it) so our best guess was that this may be causing the problem. However, I was just wondering if anyone could give a full explanation as to why connecting to FMS causes these issues, and why, if it is the problem, would running something at 200hz cause this issue.
Have you talked to the CSA at your event?
We didn’t get a chance to talk to them about the issue/why running a faster loop + a logging loop might cause an issue but one of them did diagnose the problem. I’ll try and ask more people for help tomorrow, but we had to leave right after figuring out the problem(we just removed the gyro code and it worked fine).
There’s a bug in their driver. I talked to the developer at Palmetto regional. He promises to fix and provide a new release soon. I’ve written up details on the github site. Thread that reads the gyro is not properly checking data size against buffer size before reading into it and the thread crashes.
We have a competition tomorrow. Should we remove our gyro code tonight? It sounds like it’s not going to work with fms, right?
I had a look at the driver github site and did not see a new release. The driver may work for you or it may not… you might try it in a practice round.
At palmetto last weekend gyro would not work after we flashed our radio and tethered to the bot vs using wireless network.
We just pushed a release to the 470 driver that should mitigate any start-up or overflow issues. The updated driver has also been pushed to the Maven repository.
Is there any issue with the other Analog Devices IMU available from FIRST Choice? Because that’s what we’re using.
r3 has been compiled with Java 13. The Java teams are on Java 11. We can not use r3.
This was also reported for the most recent release of the 16448 driver. @juchong
I pushed updates to the 448 and 470 drivers over the weekend!
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.