Announcement

Collapse
No announcement yet.

Robot Controller app hanging

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Robot Controller app hanging

    After playing with Vuforia repeatedly for a long time, the robot controller app started hanging (i.e. the camera view is frozen). I can kill the robot controller app by pressing the stop button on the driver station phone. The robot controller app will restart. But once this hanging got started, it hung very quickly every time I played with Vuforia. The only thing I discovered so far to get out of this is to reboot the robot controller phone. Then I am "back to normal" for a while until I played with Vuforia again for many rounds and the hanging will start again. So far this is an observation. But it reminded me of a problem when we did vision processing with NIVision on FRC where the NIVision code was written in native C++ so Java doesn't memory manage its frame buffers and we had to explicitly free up memory when done using them or else we will end up running out of memory. Is Vuforia having the same issue?

  • #2
    Originally posted by mikets View Post
    After playing with Vuforia repeatedly for a long time, the robot controller app started hanging (i.e. the camera view is frozen).
    Yes, Unfortunately there is a recently discovered bug in the SDK vuforia code in the VuforiaTrackableImpl.setLocation() and getLocation() calls.
    The bug highlighted a timing condition causing a deadlock situation. It has been fixed and will be part of the next release.

    I don't know if it helps, but I discovered this bug when I was doing a sleep operation in my opmode in order to pace the control cycle.
    This caused the Vuforia bug to randomly occur. When I took out the sleep, the bug did not occur.

    Naturally, this isn't the fix, but I just thought that you may find some relief if you can modify your loop timing.
    It seems that if the getLocation() function is called more frequently it hides the problem somewhat.

    Phil.

    Comment


    • #3
      Originally posted by Philbot View Post
      Yes, Unfortunately there is a recently discovered bug in the SDK vuforia code in the VuforiaTrackableImpl.setLocation() and getLocation() calls.
      The bug highlighted a timing condition causing a deadlock situation. It has been fixed and will be part of the next release.

      I don't know if it helps, but I discovered this bug when I was doing a sleep operation in my opmode in order to pace the control cycle.
      This caused the Vuforia bug to randomly occur. When I took out the sleep, the bug did not occur.

      Naturally, this isn't the fix, but I just thought that you may find some relief if you can modify your loop timing.
      It seems that if the getLocation() function is called more frequently it hides the problem somewhat.

      Phil.
      Hmm, that's interesting. I did a setLocation once for each target in init but I don't do getLocation. I called the listener.getPose to get the location of the target relative to the camera. I assume getLocation could be called internally by getPose then? In any case, I just need to know it's not something I did incorrectly that caused this. Do you have any idea when the next release is coming out?

      Comment


      • #4
        Originally posted by mikets View Post
        Hmm, that's interesting. I did a setLocation once for each target in init but I don't do getLocation. I called the listener.getPose to get the location of the target relative to the camera. I assume getLocation could be called internally by getPose then? In any case, I just need to know it's not something I did incorrectly that caused this. Do you have any idea when the next release is coming out?
        Not really. October.....

        Comment


        • #5
          Originally posted by Philbot View Post
          Not really. October.....
          The latest FTC_SDK beta was released today....

          It now includes the Vuforia fix that we discussed.

          Note: This latest BETA should NOT be considered "experimental".
          Rather, it addresses many of the recent issues, concerns and bugs that have been reported and discussed on this forum.
          The developers are working towards ever increasing reliability and predictability.

          So.. if you've been having issues with the current master, you may want to give the BETA a try.
          The goal would be for it to end up being an official release at some time.

          Here are the changes listed in the readme:

          Version 2.35 (released on 16.10.06)

          Blockly programming mode - Removed unnecesary idle() call from blocks for new project.
          Version 2.30 (released on 16.10.05)

          Blockly programming mode:
          Mechanism added to save Blockly op modes from Programming Mode Server onto local device
          To avoid clutter, blocks are displayed in categorized folders
          Added support for DigitalChannel
          Added support for ModernRoboticsI2cCompassSensor
          Added support for ModernRoboticsI2cRangeSensor
          Added support for VoltageSensor
          Added support for AnalogInput
          Added support for AnalogOutput
          Fix for CompassSensor setMode block

          Vuforia
          Fix deadlock
          Make camera data available while Vuforia is running.
          Update to Vuforia 6.0.117 (recommended by Vuforia and Google to close security loophole).

          Fix for autonomous 30 second timer bug (where timer was in effect, even though it appeared to have timed out).
          opModeIsActive changes to allow cleanup after op mode is stopped (with enforced 2 second safety timeout).
          Fix to avoid reading i2c twice.
          Updated sample Op Modes.
          Improved logging and fixed intermittent freezing.
          Added digital I/O sample.
          Cleaned up device names in remaining sample op modes to be consistent with Pushbot guide.
          Fix to allow use of IrSeekerSensorV3.

          Comment


          • #6
            Vuforia
            Fix deadlock
            Make camera data available while Vuforia is running.
            Thanks, Phil. Can you elaborate on exactly how the camera data is made available? Is this documented anywhere?

            Comment


            • #7
              The exposition of the camera data is discussed at length here: https://github.com/ftctechnh/ftc_app/issues/187

              Comment


              • #8
                Originally posted by FTC0417 View Post
                The exposition of the camera data is discussed at length here: https://github.com/ftctechnh/ftc_app/issues/187
                Yeah, I've read that issue thread and followed the excellent videos from team 3491.

                But for example, that issue thread says in part "There are two solutions to this. First, a hack that will work with the existing release (but may not be supported long term), and second, an architected solution that should go out in the next release." So what exactly was done? Was the hack implemented as a permanent solution? Or was the "architected solution" implemented? How does this impact the 3491 solution which exposes a Vuforia Image named rgb? Is there a new or modified template opMode that shows how the image data may be accessed and used?

                It would be great to have a sample opMode and/or small whitepaper explaining how image data can be accessed and used.

                Comment


                • #9
                  The architected solution was implemented. Either solution gives you Vuforia Frame's; all of processing of such Frames as described by FTC3491 is applicable either way. Vuforia Frames are documented here and here (the Java and the C++ version mirror each other, but I've found that the documentation for the latter is at times more clear).

                  Comment


                  • #10
                    Originally posted by FTC0417 View Post
                    The architected solution was implemented. Either solution gives you Vuforia Frame's; all of processing of such Frames as described by FTC3491 is applicable either way. Vuforia Frames are documented here and here (the Java and the C++ version mirror each other, but I've found that the documentation for the latter is at times more clear).
                    Thanks! ...

                    Comment

                    Working...
                    X