I2C drivers in onbot java require robot restart after every rebuild

Software
1

This also has been filed as a GitHub issue, but there was a suggestion to bring it up here as well. The GitHub issue is at custom i2c drivers in OnBot Java always require robot restart on rebuild · Issue #565 · FIRST-Tech-Challenge/FtcRobotController · GitHub .

We have a number of I2C sensors and devices attached to our robot, for which we’ve written I2C device drivers per the guide at Writing an I2C Driver · FIRST-Tech-Challenge/FtcRobotController Wiki · GitHub . As far as we can tell the I2C device code works fine in OnBot Java.

However, whenever we do an OnBot Java build, the I2C hardware devices are unavailable via the hardwareMap until we do a Robot Restart from the driver station. This occurs even if the rebuild didn’t involve any changes to the I2C driver code itself.

So, I have a lot of theories as to why this is the case – I suspect that doing a “Build Everything” in OnBot Java creates a new .class file for the I2C driver classes, while the hardwareMap retains references to the older class bytecode until a robot restart is performed.

Regardless of the reason, is there anything that we can do to avoid having to manually restart the robot after every rebuild? Things we would be happy to consider doing:

  1. Create a .jar or .aar library containing our I2C device classes and upload that into OnBot Java as an external library. We’ve been unable to locate any guides or resources about steps needed to do this, however. (We would be fine with generating the library from Android Studio, if we knew what to do.)

  2. Have the “build” button in OnBot Java automatically restart the robot (or update the hardware map) when it is completed. Yes, this will add a little time after each build, but it’s not really different from what happens when building code in Android Studio.

  3. …?

We’ve considered just using Android Studio full time for development, but our Android Studio builds are horribly slow on the computers we have, they still result in a robot restart (automatic, not manual), and we like the rapid iteration time of OnBot Java.

Thanks in advance for any advice or suggestions. I can also be reached as “pmichaud” on Discord and other avenues if interactive discussions are helpful.

Pm

  • Coach, FTC #7172 “Technical Difficulties”
2

Hi! :slight_smile: I can absolutely see where the frustration is coming from; slow deploy cycles are really really annoying especially when trying to tune autonomous programs.

So, I have a lot of theories as to why this is the case – I suspect that doing a “Build Everything” in OnBot Java creates a new .class file for the I2C driver classes, while the hardwareMap retains references to the older class bytecode until a robot restart is performed.

Going off memory - yes, this is correct.

As for the workarounds you mentioned -

  1. Create a .jar or .aar library containing our I2C device classes and upload that into OnBot Java as an external library. We’ve been unable to locate any guides or resources about steps needed to do this, however. (We would be fine with generating the library from Android Studio, if we knew what to do.)

This is definitely your best course of action, I think, at least for the immediate present. Unfortunately we do not as of yet have a documentation page that I can point you to for this, but you could use this repository as a template, and simply add your driver and build the AAR from there: GitHub - OpenFTC/I2C-Drivers: A collection of I2C drivers for devices not supported out of the box in the FTC SDK

I will see if we can get a docs page up soon, as well as discuss with the rest of the Tech Team to see if there is a more elegant solution possible besides the two you’ve mentioned.

-Michael

3

Wow, generating the aar from the I2C-Drivers repo works great! Thank you so much!!

When we have our drivers a bit more mature, should we consider contributing them to the OpenFTC/I2C-Drivers project…?

Pm

4

You’re very welcome :slight_smile:

As for contributing drivers, you definitely can consider it if you’d like to.