Skip to content
This repository has been archived by the owner on Oct 27, 2020. It is now read-only.

NullPointerException with bulk caching #232

Closed
cdbbnnyCode opened this issue Feb 8, 2020 · 7 comments
Closed

NullPointerException with bulk caching #232

cdbbnnyCode opened this issue Feb 8, 2020 · 7 comments

Comments

@cdbbnnyCode
Copy link

When using BulkCachingMode.AUTO, OpModes crash with the error
java.lang.NullPointerException: Attempt to invoke virtual method 'boolean com.qualcomm.hardware.lynx.LynxModule$BulkData.getDigitalChannelState(int)' on a null object reference
when reading from digital channels.

@Windwoes
Copy link
Member

Windwoes commented Feb 8, 2020

It appears there is a bug in the implementation here. getBulkData() is equipped to handle NACKs from the module by returning placeholder data, but the recordBulkCachingCommandIntent() method ignores the return value of getBulkData(), simply looking at lastBulkData instead.

I haven't tested this, but I believe the issue can be fixed by doing the following: OpenFTC/Extracted-RC@db88b6f

@realquantumcookie
Copy link

This also happens for encoder readings from the expansion hub. Please fix this issue ASAP...

@Windwoes
Copy link
Member

Windwoes commented Feb 16, 2020

@ToiletCommander Judging from the release schedule as of late, it will probably be a while before this is fixed. As a workaround, you could turn bulk caching off and instead directly interpret the return values from getBulkData() as this will avoid the issue.

@realquantumcookie
Copy link

@FROGbots-4634 Thank you for your advice, we have a state tournament next weekend and I have just recently changed our library to do MANUAL Bulk Read(with a data refresh every cycle my library does a cycle), which in theory should boost the performance of everything (especially trajectory follow responsiveness).
It would be a pain in the ass for me to change back to no caching and let every wrapped-up sensor class read from BulkData class...
Any est. release date I can refer to that you know of?

@realquantumcookie
Copy link

I was able to find a way to work around it...And this is for MANUAL MODE ONLY
If you are using MANUAL mode, you can add the following code after your clearBulkCache() function.

Before:

for(LynxModule i : allExtensionHubs){
    i.clearBulkCache();
}

After:

for(LynxModule i : allExtensionHubs){
    i.clearBulkCache();
    try {
        Class<LynxModule> LynxModuleClass = LynxModule.class;
        Field lynxModuleField = LynxModuleClass.getDeclaredField("lastBulkData");
        lynxModuleField.setAccessible(true);
        lynxModuleField.set(i,i.getBulkData());
    }catch(NoSuchFieldException|IllegalAccessException e){
        e.printStackTrace();
    }
}

As clearBulkCache() function sets the lastBulkData to null, we can prevent the bug from happening by manually assign a new data to it, this guarentees that lastBulkData is never set to null.

@David10238
Copy link

Fixing it to just use the last bulk data would be good, but I would like to also see a .didLastReadFail method and the ability to easily stop an opmode with a custom message (you might not want to continue auto if it dc'd). stopping with a custom message could also be a good debugging tool to serve the same function as exceptions while being more user friendly. api could just be requestOpModeStop("insert some message here")

@NoahAndrews
Copy link
Member

This was closed because it's fixed in version 5.5.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants