Announcement

Collapse
No announcement yet.

Testing Android-based robot while waiting on Modern Robotics

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

  • Testing Android-based robot while waiting on Modern Robotics

    We've been experimenting with Android-based robotics while waiting for our MR modules and have come up with an acceptable chromovore using the ZTE's forward facing camera. For computer vision we are using OpenCV4Android. For low-level IO we are using the IOIO-OTG open source solution - so this is not using the FTC SDK. But it's given us a decent start on learning about controlling a robot from an Android app. More info and a video can be found on our blog entry:
    http://www.ironreignrobotics.com/Arg...ed-chromovore/

    We hope this give teams some ideas about how to experiment while waiting. And though we have no idea if color detection will be useful in the upcoming season, it doesn't hurt to have it in your bag of tricks.

  • #2
    Unfortunately, I think Tom Eng previously said that the Android NDK would probably not be allowed, which is what OpenCV4Android uses.

    ~liam

    Comment


    • #3
      In case you missed the topic, here is the quote specifying the use of the NDK.

      Originally posted by Tom Eng View Post
      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
      The requirement of the NDK for OpenCV was specified here:

      http://docs.opencv.org/doc/tutorials...ocv-on-android
      Prerequisite 2 (Android SDK and NDK)

      But, good job programming this, I hope the best for your team. It (or anything like this) makes good practice in general. Just realize that it will not be competition legal, unless we are informed otherwise.

      Comment


      • #4
        Thanks for the feedback, but I'll just correct a misconception. You've quoted the prerequisite for the tutorial which happens to include how to use opencv via the NDK. Under opencv, the NDK is an option that will indeed provide performance gains. But it's only an option. Only one of the samples that ships with it uses the NDK. The rest, including the colorblobdetect sample that we based our experiments on, all use straight java. And there are many other ways to use the cameras - you don't have to use opencv. Though I see no reason to forbid any specific implementation of vision processing libraries - and opencv is world class and pretty much the standard in college. It would be a shame to arbitrarily prevent students from getting exposure to this area of research. Also, in a number of the early promos about the switch to Android, the cameras were touted as a benefit of the new platform. I can't imagine that FTC would plan to ban their use regardless of how useful they might turn out to be.

        All that said, I believe embargoing the NDK is an idea that is inconsistent with innovation. I have very limited experience in Android, but I have used the NDK experimentally. That experience and everything I have read about it suggests that the NDK is not for beginners. It is less well documented, and I could not recommend going the native code route unless there was no other option. But I also would not forbid it.

        Trying to read between the lines of the Tom quote, it looks like it might be targeted at saying that we cannot use a purely native implementation that avoids the FTC SDK. But what about blended apps? In most uses of the NDK that I've seen, the app is implemented on Dalvik, but for a subset of performance sensitive functions it makes calls via java wrappers into some limited native C++ code via the NDK. It's akin to being able to write drivers in user space? Why would that be forbidden? The main control loops would still be executing in the context of the FTC SDK in Dalvik.

        So I'm getting off-subject here. OpenCV doesn't require use of the NDK and cameras were promoted as a benefit of the new platform so this should be legal (use of the IOIO and the crawler platform notwithstanding):
        http://www.ironreignrobotics.com/Arg...ed-chromovore/

        Thanks,

        Karim
        Coach for Iron Reign

        Comment


        • #5
          Hear, hear, Karim!

          Comment


          • #6
            Since, you are not using the FTC SDK for that demo, you should be fine.

            As for not allowing the NDK, I would like to see more defition to that, such that it answers the questions of "What if the NDK is used in a "off-the-shelf" library, such as OpenCV?;" "Is user code the only code not allowed to use the NDK at all, or am I allowed to use it in my team's libraries that have their source code released?" "Will the complete functionality and usage of the NDK be allowed or supported at a later date?" "Will only a subset of the library be available for usage?"

            I don't see how OpenCV4Android does not use the NDK at all, unless you aren't building the source, and you are not playing the C++ sections.

            Comment


            • #7
              OpenCV4Android is technically the C++ backend of OpenCV compiled through the NDK with Java bindings.
              Even if you're not using the NDK for developing your app, your "straight Java" is linked against a C++ library.

              Comment


              • #8
                BoofCV is pure Java though, in case anyone wants to know about NDK-less CV libraries

                Comment


                • #9
                  I agree that there are many questions about the NDK - especially since it's not possible to use Android without calling into native code. Even something like System.nanoTime() will map into a library originally written in C/C++. And there is no safe boundary to say where 3rd party libraries should start being disallowed. If you are using the gyro on a phone that has one (the ZTE speed doesn't), then the orientation provider is likely a manufacturer-specific implementation. And it's not written in java. Are we going to restrict access to libraries & functionality that ship with a single specific device? Disallow updates? The big question is why? What is the benefit of these restrictions. FTC has a long history of overcoming self-imposed restrictions that seemed necessary at the time but proved unnecessary and untenable over time. There was once a time when it was debated whether nyloc nuts were legal... Nuts...

                  We did not compile OpenCV4Android from source. We didn't write anything in C++. You can link directly to a precompiled library or you can dynamically link at runtime through the OpenCVManager app that you can find in Google Play. You also have the option of writing higher level functions in C++ and using the NDK to create your own wrappers to those higher level functions and it could be slightly faster - but that would require team use of the NDK. I think that's actually an argument for why restricting use of the NDK is a pretty artificial restriction.

                  If this sounds ranty - I don't mean it that way. I'm just pleading for freedom to innovate. I'd rather be talking about the possibilities and the many challenges of computer vision in a competition context than about which library is legal.

                  Comment


                  • #10
                    Right now this is my statement on the NDK usage, (please note that I don't represent FIRST, FTC or their views or know them). Until further notice by FIRST officials, we should not use any functionality of NDK that requires the NDK to be installed on the system in which the robot app is complied on. If that functionality can be used via the SDK, without usage of any NDK currently or previously installed on the team's development computer, that should be allowed. As far as what is legal in regard to languages that are not ran in Dalvik VM and that must be complied, I do not recommend writing applications that use those languages for competition usage.

                    As far as third-party libraries, I would just apply that usage statement above, and see if it fits (until FIRST releases something that says otherwise.) Anyway, disallowing the NDK could only be fruitful by preventing more errors and undefined behavior (both good and bad; it makes better programmers when done right, and causes more issues for FIRST). I hope the NDK could be used soon.

                    Comment

                    Working...
                    X