Our process for upgrading to a new SDK. Code and phones.

[Philbot]

Hi

The process for upgrading to a new SDK (Software Development Kit) is not difficult, but there ARE a lot of steps when you consider the code, and deploying both apps.

I thought I would list (in detail) the steps we went through to try out the new 1.6 Beta code.
This is definitely NOT the only way to do this, but it's our way, and it's very repeatable.

Specific example: ftc_app V 1.5 to ftc_app-beta V1.6

Phase 1: Backup existing project & download new SDK.

This is by far the MOST important step to get correct. I like to rename my current working folder so it CAN NOT get overwritten. Then I transfer down and test then new SDK before making any changes.

• Rename /users/phil/AndroidStudioProjects/ftc_app folder to ftc_app-2016-02-10
• Log into github: https://github.com/ftctechnh/ftc_app
• Change to the beta branch (click on “branch”, then pull-0down and select “beta”)
• Download copy of SDK by clicking on Download Zip button
• Make note of location where zip file is downloaded
• Once complete, unzip file as /users/phil/AndroidStudioProjects/ftc_app-beta . This now becomes my new project folder.
• Verify that the project is good, by running Android Studio and doing an “Import Project” on the new project folder (top most level) and then run “Build / Clean Build”
• Verify that no errors occur. Correct any problems BEFORE continuing.
• Exit out of Android Studios

Phase 2: Merge custom team code with new project

Next you must transfer any of your custom code into the new project folder. To do this I open up two Explorer windows side by side. Old (renamed) folder on the left, new (downloaded) folder on the right.

• Navigate both project folder trees down to the opmode folder: \FtcRobotController\src\main\java\com\qualcomm\ftc robotcontroller\opmodes
• Ctrl-Drag (COPY) all of the team’s custom opmodes (xxxxxx.java files) from the old to the new folder.
• Ctrl-Drag (COPY) the team’s FtcOpModeRegister.java file from the old to the new folder.
• Verify that the updated project is good, by running Android Studio and doing an “Import Project” (again) on the new project folder (top most level) and then run “Build / Clean Build”
• Verify that no errors occur. Correct any problems BEFORE continuing.

Phase 3: Building and deploying new project to the Robot Controller

This new revision will not simply “overwrite” the existing app on the Robot Controller phone. You need to allow Android Studio to delete it before deploying the new app. Then you need to reconnect any disconnected elements.

• Start Android Studios and open the new project. Give it time to fully run all gradle scripts (status at bottom).
• Open the Gradle Monitor tab at the bottom of the screen.
• Plug your RC phone into your development computer. Verify that the phone is seen as a connected device
• Deploy the app by pressing the green RUN arrow.
• You will be prompted that the new app is not compatible with the old app. Accept the option to continue anyway. The existing app will be deleted and the new one will replace it, and start running.
• The RC App will have “forgotten” the current robot configuration, so use the App “Settings” menu to “select” and “activate” the correct robot configuration.
• Close the app, and swipe it off (Press and hold lower menu button). Ignore any error messages.
• We like to have the RC app on the start screen, so we select the Apps Icon (9 squares), locate the RC app and then drag it to the start screen. This is just a convenience.
• With the Robot’s 12V power turned off, place the phone in the robot and connect the USB cable.
• Turn on the 12V. Observe that the Robot Controller App is launched.
• Since this is essentially a “New” app, it will create notifications that it wants to be associated with the USB hardware devices. It will pop up a black dialog box for EACH device. Check the “checkbox” and accept the dialog. To ensure that ALL the devices are associated, you will need to hit the Phone’s Back button (lower left) and then re-start the App several times until the dialog boxes stop appearing.
• Once the dialog box no longer appears, the app is fully installed and configured.

Phase 4: Install the new matching Driver station

Since the communications protocols may change form version to version, it’s REQUIRED that the corresponding Driver Station App is loaded on the Driver station phone. This can be done several ways. But the description below details how we “side load” the app using windows.

• Delete the current Driver Station App from the phone. Select: “Settings/Apps” and locate the FTC Driver Station Icon. Click it and select Uninstall. Agree to all options.
• Ensure that your phone will accept “side loaded” apps. Select: “Settings/Security” and make sure “unknown Sources” is checked.
• Place the Driver Station phone in media mode. Select: “Settings/Connect to PC” menu to check “Media device”. This means that when the phone is connected to a PC it will appear as an external drive. (note: put this back to “charge only” when install is complete)
• Plug the DS phone into your Development PC and wait for it to appear as a drive labeled: N9130 You can Open Drive to view files.
• Copy the App from the computer to the phone in order to install it. It is located in the ftc_app-beta folder in the /doc/apk sub-folder. It is named FtcDriverStation-release.apk Copy the file, and paste it into the N9130/Phone folder.
• Install the new Driver Station app. Click on the phone’s App Icon (9 squares) and locate the File Manager App. Select it. Scroll to the right to see the list of folders on the phone. Scroll down past the folders until you see the FTCDriverStation file. Select it and then press Install. Press open to run the installed app.
• You may be presented with a screen that says Configuring WiFi Direct. This screen has a bug and it may not seem to complete. Simply count to 10 and then hit the phone’s back button.
• All that remains is to re-pair with your robot controller. Select the App’s setting button and choose “Pair with Robot”. Your robot must be on and have the RC app running. It should also be given a correct FTC network name eg: 2818-RC.

Phase 5: Verify that all of your opmodes work correctly with the new SDK

Phil.

[BinaryChaos]

Thatis really Helpful

[jdkunzeman]

Thank you very much!

[dlevy]

Mac users will have difficulty with transferring the files in this manner. There are additional tools that can help however I find the following approach as a very simple alternative to Phase 4 as stated above:

1) copy the driver station apk frpm the sdk's doc/apk directory onto a thumb drive
2) connect the thumb drive to your DS phone with the OTG cable used for the gamepad.
3) Open the File Manager app on the phone, locate the apk on the thumbdrive ( usb tab) , and click to install. No need to copy the apk onto the phone.

[dmssargent]

Wow Philbot that process is a bit more involved than what I use.

To update Xtensible, I git pull origin master, then copy the files over by hand (usually just the aar files), and put them into their locations within the FtcSdk module, gradlew clean build, takes care of all of the configuration issues caused by doing that, fix any issues, commit the result, deploy the app to the RC, and plug the phone back in to the robot. If needed I update the DS with the command (with the DS plugged in and all other phones disconnected) "adb install doc/apk/*Driver*.apk". Everything just works afterwards. No need to worry about the backups, if the process succeeds.

[FTC0417]

dmssargent, even that surprises me with the amount of handwork involved. Can't git pretty much entirely automate this? Setting that up takes some git savvy, to be sure, but it's pretty cookbook, and a one-time thing.

Having originally forked the master branch from FTC HQ to one's own repository on GitHub, one clones that locally in the usual way. In the local clone, your github repo is the git remote named 'origin'. To that remote, add a second remote back to HQ with

git remote add FTCHQRemote https://github.com/ftctechnh/ftc_app.git

Having done that, simply fetching / pulling from the 'FTCHQRemote' (chosing either the master or beta branch) into your local clone instead of from the 'origin' remote will give you new changes. That's it. You can then push them up to your origin/master (or whichever) branch to share them with other members of your team, much as you would push up and share edits and changes you made yourself. In both cases, your other team members pull from origin/master to keep in sync.

As an added bonus: you get backups entirely and completely for free, as it's all just sitting there it GitHub.

[dmssargent]

dmssargent, even that surprises me with the amount of handwork involved. Can't git pretty much entirely automate this? Setting that up takes some git savvy, to be sure, but it's pretty cookbook, and a one-time thing.

Having originally forked the master branch from FTC HQ to one's own repository on GitHub, one clones that locally in the usual way. In the local clone, your github repo is the git remote named 'origin'. To that remote, add a second remote back to HQ with

git remote add FTCHQRemote https://github.com/ftctechnh/ftc_app.git

Having done that, simply fetching / pulling from the 'FTCHQRemote' (chosing either the master or beta branch) into your local clone instead of from the 'origin' remote will give you new changes. That's it. You can then push them up to your origin/master (or whichever) branch to share them with other members of your team, much as you would push up and share edits and changes you made yourself. In both cases, your other team members pull from origin/master to keep in sync.

As an added bonus: you get backups entirely and completely for free, as it's all just sitting there it GitHub.

That will only work sometimes, just too many locations have changed to have git do it for me (and it put everything in the right place with the correct new versions) (my structure of the FTC SDK is radically different than how the origin branch looks, https://github.com/dmssargent/Xtensible-ftc_app). The FTC SDK for me is in its on Gradle module with the FTC Robot Controller module dependent on it to make migration easier.

FTC0419, I upgrade the original code and simple Android Studio teams the way you described.

[FTC0417]

dmssargent, point well taken.

But for those who are basically taking the SDK and doing little more than adding their own OpModes to it, this should be entirely cookie-cutter automatable, right?

[GearTicks]

dmssargent, point well taken.

But for those who are basically taking the SDK and doing little more than adding their own OpModes to it, this should be entirely cookie-cutter automatable, right?

Yes, if there aren't going to be any merge conflicts, it has worked well for us to simply pull from the remote. If you move or modify FTC files that are updated each update, it becomes significantly more difficult.

[dmssargent]

Yes, if there aren't going to be any merge conflicts, it has worked well for us to simply pull from the remote. If you move or modify FTC files that are updated each update, it becomes significantly more difficult.

The amount of merge conflicts was about 100+ before I made the FTC SDK into its own Gradle Module, it is dropped to around 5.

dmssargent, point well taken.

But for those who are basically taking the SDK and doing little more than adding their own OpModes to it, this should be entirely cookie-cutter automatable, right?

Yes, as GearTicks pointed out, you can basically "git pull origin" to update your code for most people (or if you are feeling adventurous and want to upgrade in a (&& stops as soon as one command returns a non-zero return value in my experience) backup branch run this is cmd "git add -A && git commit && git checkout -b ftc_upgrade && git pull upstream && gradlew clean build && git commit" (note that this doesn't change back to the master branch and upgrade that or deploy any app to any phone)

[Philbot]

Wow Philbot that process is a bit more involved than what I use.

To update Xtensible, I git pull origin master, then copy the files over by hand (usually just the aar files), and put them into their locations within the FtcSdk module, gradlew clean build, takes care of all of the configuration issues caused by doing that, fix any issues, commit the result, deploy the app to the RC, and plug the phone back in to the robot. If needed I update the DS with the command (with the DS plugged in and all other phones disconnected) "adb install doc/apk/*Driver*.apk". Everything just works afterwards. No need to worry about the backups, if the process succeeds.

That doesn't surprize me based on your strong understanding of the development process, but how many people do you think could use your process without a good knowledge of GIT and ADB command lines?
I would suggest that your "simplified" description is usable by about 5% of the teams, and the rest will either never do an update,or will blame the update for their lack of understanding of the process.

eg: Unless you are a hard core developer, the idea of "git pull origin master" is about as understandable as the martian language.
This is illustrated by how many people are generating invalid pull requests on the master code. I don't want to be "that guy", so I take the more 'old school' approach.

My explanation is designed to be used by people like me, who aren't comfortable with GIT and manually running ADB commands.
(It's not from lack of trying, but they just seem to introduce more problems than a basic copy paste.)

My explanation also attempts to anticipate problems, and prevent them, rather than assume the user knows how to deal with error messages and unexpected prompts.

I also tried to explain (in great detail) steps that I'm clearly seeing that many teams don't understand.
(like the fact that new app versions won't naturally replace older ones, or that the DS must ALSO be updated)

I wish I lived in the "Everything just works afterwards." world

Phil.

[FTC6389]

That doesn't surprize me based on your strong understanding of the development process, but how many people do you think could use your process without a good knowledge of GIT and ADB command lines?
I would suggest that your "simplified" description is usable by about 5% of the teams, and the rest will either never do an update,or will blame the update for their lack of understanding of the process.

eg: Unless you are a hard core developer, the idea of "git pull origin master" is about as understandable as the martian language.
This is illustrated by how many people are generating invalid pull requests on the master code. I don't want to be "that guy", so I take the more 'old school' approach.

My explanation is designed to be used by people like me, who aren't comfortable with GIT and manually running ADB commands.
(It's not from lack of trying, but they just seem to introduce more problems than a basic copy paste.)

My explanation also attempts to anticipate problems, and prevent them, rather than assume the user knows how to deal with error messages and unexpected prompts.

I also tried to explain (in great detail) steps that I'm clearly seeing that many teams don't understand.
(like the fact that new app versions won't naturally replace older ones, or that the DS must ALSO be updated)

I wish I lived in the "Everything just works afterwards." world

Phil.

And THIS is why Phil deserves a nomination for the "Helpful FTC Forum Poster of The Year" award! This award is presented to the FTC community member who selflessly and tirelessly figures out the convoluted mess that FTC has become, and posts straightforward, easily understandable sets of instructions designed to help FTC teams get their robots working!



- The Lazybotts

[Philbot]

And THIS is why Phil deserves a nomination for the "Helpful FTC Forum Poster of The Year" award! This award is presented to the FTC community member who selflessly and tirelessly figures out the convoluted mess that FTC has become, and posts straightforward, easily understandable sets of instructions designed to help FTC teams get their robots working!



- The Lazybotts

Thanks.... LOL.

[dmssargent]

That doesn't surprize me based on your strong understanding of the development process, but how many people do you think could use your process without a good knowledge of GIT and ADB command lines?
I would suggest that your "simplified" description is usable by about 5% of the teams, and the rest will either never do an update,or will blame the update for their lack of understanding of the process.

eg: Unless you are a hard core developer, the idea of "git pull origin master" is about as understandable as the martian language.
This is illustrated by how many people are generating invalid pull requests on the master code. I don't want to be "that guy", so I take the more 'old school' approach.

My explanation is designed to be used by people like me, who aren't comfortable with GIT and manually running ADB commands.
(It's not from lack of trying, but they just seem to introduce more problems than a basic copy paste.)

My explanation also attempts to anticipate problems, and prevent them, rather than assume the user knows how to deal with error messages and unexpected prompts.

I also tried to explain (in great detail) steps that I'm clearly seeing that many teams don't understand.
(like the fact that new app versions won't naturally replace older ones, or that the DS must ALSO be updated)

I wish I lived in the "Everything just works afterwards." world

Phil.

Thanks for the constructive criticism and the compliments. I really need any feedback I can get about what is revelant to the FTC community.
I wish everyone's team and all of the mentors of all of the FIRST programs the best of luck.

[ketterrm]

This Post really helped. We just noticed the Driver Station got updated to 1.5 as we had auto updates on, and we couldn't connect with the Robot Controller! We updated the robot controller with these instructions to 1.5 and now we are back!

And now we understand how we can try beta versions.