No announcement yet.

Testing faster

  • Filter
  • Time
  • Show
Clear All
new posts

  • Testing faster

    Does anybody have an idea for making testing more efficient? It seems really slow to have to take out the phone each time, plug it in, download, then put it back. I remember FLL had a bluetooth function for download. Anybody know of a similar thing for FTC?

  • #2

    I'm assuming you are not using Blocks or OnBot Java, both of which are hosted on the RC phone, connected wirelessly to your laptop. There's no 'downloading', since the code already resides on the RC.

    Android wireless debugging (ADB) is the official way to connect wirelessly between Android Studio and the RC phone. There are various ways to use ADB, here are a couple of discussions:

    But there is another way, very fast. Some teams copy their Android Studio code, and paste it directly into an open OnBot Java session. Often with little or no editing, the code can be transferred, built and run quicker than using ADB.

    It can literally be: control-A, control-C, control-A, control-V.

    This copy/paste method has limitations, but for fast wireless testing cycles, it might suit your needs.


    • #3
      Westside Thank you very much!


      • #4
        During the Relic Recovery season, OpenRC Turbo allowed for sub-10-second wireless deploys of the entire RC app. The OpenFTC Team will be updating it to be based on SDK v5.0 so that it's legal for competition, and hopefully Turbo will again be able to again provide those fast deploys.


        • #5
          One of the benefits of using over-the-air ADB rather than copy-and-paste to on-blocks, is access to the debugging environment (the "DB" in ADB) in Android Studio. For some problems it is handy to set a breakpoint, have the robot pause, and have the software team take a look at the current values of variables in the code.

          Another thing I'd promote, which is something I had our software team work on over the summer, is to be more like the software industry and rely not just on integration testing (with the robot), but write unit tests. It's pretty straightforward to write working mocks of the core pieces of the SDK (motors, gamepads, servos, sensors, etc) and make sure that the code that is being written at least does the correct thing when the sensor does the right thing, or does the expected thing when there's an interaction from a human operator. Having code known to work on the "happy path" will shorten the development cycle as well.

          Unit tests are also one of the few ways to simulate the "unhappy" (unexpected states) path, which will make your code much more robust as well.

          Our software team managed to mock up enough of the FTC SDK that they were able to test all of the paths of their scoring mechanism from Rover Ruckus, which was an elevator with a PID controller running up/down, and a state machine that kept the rest of the parts of the mechanism in the correct positions while the robot was running and interacting with human operator requests.

          Had they been able to do that during the season, that bit of code would've been integrated more quickly, and with better quality than it was (although, the first integration was done in an evening, which was pretty good!).


          • #6
            FYI OpenRC-Turbo has been updated to SDK v5.1 and cuts the APK size from 27MB down to just 4MB while still retaining an easy way to build a competition-legal app for when you're going to an event.