Announcement

Collapse
No announcement yet.

Android NDK

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

  • Android NDK

    Android supports a Native Development Kit (http://developer.android.com/tools/sdk/ndk/index.html), which lets you write native code with c and c++ on Android devices. It includes the Java Native Interface, which would allow us to interface with Java to access the operating system and robot hardware. Will we be allowed to program our robot using the NDK? We think that programming at a lower level will give us an opportunity to learn about software in more depth.

    Thank you,
    Team 5206 The Knights of Ni

  • #2
    Along with simply learning to program at a lower level, it would also be better to use for performance critical tasks, i.e. vision or sensor processing. It seems to be simple to implement into Android Studio according to the following link:
    https://software.intel.com/en-us/vid...android-studio
    Along with FTC5206, I am curios if we will be allowed to use the NDK in programming of our robots.

    --
    Siddharth

    Comment


    • #3
      It would be interesting if it would be allowed to use the NDK. However, since the app would probably be written in more than one languages only a subset of the subset using Android Studio and the like could maintain and develop such code. I am not sure if the performance gains of using C(++) could become negligible in an app doing most of the work in Java and already requiring abstraction for use of the FIRST SDK. The data could be written very low-level in C. Then, the C method marked as private and handed off through a maze of Java, ending up as a high-level function, or the C method is called then given a Java wrapper to pass to the client code. There is also a possibility of no C altogether to access it from, or there is no gain between the sensor updates taking much longer than any code you are writing. Also, with the driver GUI not being customizable, it increases the chance that FIRST won't support it for next year. However, there is a chance that using the NDK is their new defintion of being one of the better veteran teams. All I would recommend is to write performance benchmarks comparing NDK and SDK sensor reads (or vision processing) using what we know, take an educated guess at what we don't, publish the results, and open-source the code for others to audit.

      Comment


      • #4
        Hi Folks,

        For the initial season, we do not plan to allow the use of the NDK. Although using the NDK can result in performance gains for some applications, for the framework that has been developed by QualComm it actually would be better and less complicated to use Java code and Android's Dalvik VM.

        Tom

        Comment


        • #5
          Originally posted by Tom Eng View Post
          ....would be better and less complicated to use Java code and Android's Dalvik VM.

          Tom
          Are we constrained to Dalvik or may we use ART? I ask because Dalvik is known to pause around 10ms for garbage collection whereas Android Runtime is reported to be <2ms. If we're implementing timing critical functions in what's not really a real time OS and NDK use is precluded for now then minimising GC time would be nice. At least we're not back in the early days of Dalvik where CG could take >100ms!

          Comment


          • #6
            no Android NDK other restrictions

            Originally posted by Tom Eng View Post
            Hi Folks,

            For the initial season, we do not plan to allow the use of the NDK. [...]

            Tom
            While I understand that to use the QUALCOMM framework it might be certainly "less complicated" to stick to Java, certainly there are a good deal of teams out there (ours included) that have the expertise to deal with the NDK, or to program to the bare metal, were that necessary.


            It's fabulous and important that it be reasonably easy for novice teams to get going, and this seems (understandably) to be the focus. Conversely, however, it seems unreasonable to artificially constrain more experienced teams.


            The rules should reflect only those restrictions which are logically necessary to make the competitions run smoothly and fairly (example: in the existing world: running software which has been tested to work correctly with the field control system). In the new world as I presently understand it, such restrictions would seem few and far between. In particular, I don't see how preventing a team from using the NDK should they choose to do so would be justified.

            Comment


            • #7
              FTC0417,

              Can you elaborate on what you feel you would be missing out on by not being allowed to use the NDK? Google's own documentation, seems to go out of their way to recommend against using the NDK unless it is absolutely necessary and to assure developers that there is little to no performance improvement by using the NDK. I am just curious what real world scenarios you are thinking of or if this is just a question of principles.

              Regards,

              Eddie

              Comment


              • #8
                Originally posted by EddieD View Post
                FTC0417,

                Can you elaborate on what you feel you would be missing out on by not being allowed to use the NDK? Google's own documentation, seems to go out of their way to recommend against using the NDK unless it is absolutely necessary and to assure developers that there is little to no performance improvement by using the NDK. I am just curious what real world scenarios you are thinking of or if this is just a question of principles.

                Regards,

                Eddie
                According to this study(http://people.apache.org/~xli/papers...ing-models.pdf) you can get a significant performance improvement by using the NDK for some applications. Directly interpreting Java byte code is definitely slower than running native code, and JIT compiles are less predictable and usually worse than a static compile. It is difficult to ensure that the JIT produces good memory management, SIMD instructions, and other things critical for optimization. With native code it is easier to guarantee that you run optimized code. That said, FTC might not be the most hardware constrained. However I think it is still important to learn how to write performant code.

                Vision processing, AI, large physics simulations, image and video processing, and 3D applications are a few examples of hardware constrained software that could potentially benefit from native code.

                Comment

                Working...
                X