Navx-micro connection issues

[chen.mi...@bloomfield.org]

I have been experiencing an issue where when you download the autonomous program for the first time, the navx-micro connects perfectly, but as soon you attempt to run it again, the navx-micro is unable to connect. In the program, I gave it 3 seconds to let it attempt to connect but it has a very bad success rate. When the navx is not connected, my program falls back to a second Modern Robotics gyro.

We moved the navx-micro to a separate dim module to increase the update rate on the USB bus, but nothing changes.

I've attached an image of the navx giving back data on the example navx code running at 50 Hz.

I'm also attaching my hardware map and autonomous program along with an interface of the constants used in the program to see if anyone is able to debug it.

[admin]

Hi Chris,

I'd recommend removing this one line (it is now present in MMAutonomousRedTeamNavXTest.java):

        navxDevice.close();

Please give that a try and let us know your findings.

Last year there were a few reports of something similar to what you've reported, and removing the call to close() avoided the problem.  A navx-Micro library software release was made on 2/20/2017 to address the issue reported at that time.  So please also verify the datestamp on the navx_ftc-release.aar library file (typically installed to C:\Users\<username>\navx-micro\android\libs\).

If removing the call to close() resolves the issue and you have the latest library, please let us know that - it's possible there's an issue in the navx-mxp library, or there's an interaction w/the newer release of the ftc_app libraries that is causing a problem.

- scott

[chen.mi...@bloomfield.org]

When i try to download of the latest navx-micro build for ftc 2016, it doesnt give me any of the library code. Only this setup.exe thing and things to create the navx enclosure.

[chen.mi...@bloomfield.org]

My navx_ftc-release library is from 2/10/2017.

[chen.mi...@bloomfield.org]

Is it possible you could send me a link to download the newest library?

[admin]

You have the latest library (2/20/2017).

To install, run the setup.exe file.

- scott

[chen.mi...@bloomfield.org]

I just realized I wasn't downloading the one for Mac. I just did and the ftc_release.aar file still says Feb 10, 2017.

[admin]

Ah, I see we have another navX-Micro Mac user! :)

[chen.mi...@bloomfield.org]

So is the problem currently not fixable? I already tried to delete the close(); function. Nothing happens.

[admin]

> So is the problem currently not fixable?

This is the first we've heard of the problem; the next step is we will try to reproduce it in our lab, then we can find the root cause and then we can determine how to best fix it.

If we have trouble reproducing this issue, we'll get back to you with more questions - we may need to have you install a debug version of the library and get some logs in that case.

I'll be in touch early next week after we've had a chance to dig into this deeper.

Thanks,

- scott 

[chen.mi...@bloomfield.org]

Thank you very much!

[chen.mi...@bloomfield.org]

Hi, Scott.

I'm using Windows10 to see if the Navx-Micro library works to solve the issue. I got the windows version of the library and I removed the call to close the navxDevice. When I tested to see if the problem was solved it didn't work.  I also noticed that the date stamp on the navx_ftc-release.aar file was 2/10/2017. I downloaded it from this link http://www.pdocs.kauailabs.com/navx-mxp/software/android-library-ftc/.

[admin]

Hi Michael,

We've performed some testing w/the ftc_app 3.1 SDK and the navX-Micro libraries from 2/10/2017.

So far we haven't found any problems testing the samples that are provided w/the navX-Micro distribution.  You should be able to test these to verify proper operation of the libraries (for example, the SensorNavXProcessedOp opmode, and the ConceptNavXDriveStraightPIDLoopOp.

Since the samples work for us, it makes sense next to start looking more closely at the opmode code you have provided.

I see one thing that might be an issue:  a stale reference to the navxDevice might be being accessed.

In our op-mode examples, ~each and every time~ the opmode starts this is invoked:

        // get a reference to NavX-micro device
        navxDevice = AHRS.getInstance(hwMap.deviceInterfaceModule.get("dim2"),
                NAVX_DIM_I2C_PORT,
                AHRS.DeviceDataType.kProcessedData,
                NAVX_DEVICE_UPDATE_RATE_HZ);

This library is designed so that there will only ever be a single instance.  However, if close() is ever invoked, that instance will be shutdown and destroyed.  And a new instance will not be created until AHRS.getInstance() is invoked again.

Therefore, if close() is invoked somewhere in the code, and if some code has cached a reference to the navxDevice, after close() occurs that will be a reference to a deleted object.  I think that's likely what's happening here.

I note that in HardwareShooterBotNavXMicroTest.java in the init(HardwareMap) method, AHRS.getInstance() is invoked and the returned object reference is assigned to the navXDevice variable.  Then, in MMAutonomousRedTeamNavXTest.java, this variable is retrieved when the opmode starts, like this:

        // get a reference to the Navx device and one of its PID controllers
        navxDevice = robot.navxDevice;

So I believe what is happening is that somewhere in code, the close() method is being invoked on the navXDevice.  At that point robot.navxDevice refers to a deleted object.  And when the opmode runs a second time, it attempts to use that reference to a deleted object.

If that's correct, there are two ways to resolve it:

(a) remove all code that calls navxDevice.close().  This should cause no harm, except that the navXDevice will be continuing to gather data from the navX-Micro device even though it's not being used.  

(b) instead of accessing the reference to the navXDevice that was retrieved via AHRS.getInstance() at the beginning of the robot program, at the beginning of each opmode re-retrieve a current reference by re-invoking AHRS.getInstance() at that time.

I realize that you had previously attempted removing the call to close(), and I can't explain why you still saw the problem after that.

However what you are describing sounds very much like during the second run of the opmode, a stale reference to the navxDevice is being accessed.

So please look into that and let us know what you find.

Cheers,

- scott

[admin]

As a follow-up note, if the robot code invokes navxDevice.close(), it's also recommended not to cache the PIDController object, as well.

[chen.mi...@bloomfield.org]

Hi, Scott.

On a Mac, we used solution (b) and (a) bar and moved AHRS instances over to the main opmode. I didn't remove the .close() method call because it wouldn't work without it. I also implemented a "try, catch" statement (below) to close the device if the program is stopped mid-run so the navxDevice would still close. It seems you can't create a new AHRS object in the hardware map because it won't close causing it to fail in the second run after the download.

run opmode {

     try {

          while {

               autonomous stuff;

          }

     }

     catch {

               interrupted exception

     }

     finally {

     navxDevice.close;

     }

}

Thank you so much for your help!

[admin]

Glad to hear things are working for your team now, Michael.

I think the exception handling is a very good idea, in the case of the interrupted exception.

The one thing you wrote that surprised me is this:  "I didn't remove the .close() method call because it wouldn't work without it."  Can you please describe the behavior that happened when the call to close() was removed?  I don't have an explanation for this - our understanding is that calling close() is optional, and it'd be good to know if that's not correct.

[chen.mi...@bloomfield.org]

When I tested the program with the .close() method call removed, it couldn't connect to the navx Micro on the second run. When we added it back in and let the whole program run through, it closed navxDevice and it worked on every try afterward as long as you call the .close() method. This is also why I added the exception handling in the case of an interrupted exception.

We also the moved the navXPIDController into the main program.