Announcement

Collapse
No announcement yet.

Testing faster

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

  • 4634 Programmer
    replied
    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. https://github.com/OpenFTC/OpenRC-Turbo

    Leave a comment:


  • markdmatthews
    replied
    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!).

    Leave a comment:


  • 4634 Programmer
    replied
    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.

    Leave a comment:


  • jcwang9010
    replied
    Westside Thank you very much!

    Leave a comment:


  • Westside
    replied

    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:

    https://ftcforum.usfirst.org/forum/f...g-simplest-way

    https://ftcforum.usfirst.org/forum/f...android-studio

    .
    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.

    Leave a comment:


  • jcwang9010
    started a topic Testing faster

    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?
Working...
X