8.1.1 showing wrong battery voltage, huge delay from controllers

[Robocoder9000]

Having updated our phone and Control Hub to 8.1.1, DS is now reporting battery levels from 6-8 volts (battery was measured at 12+ volts before and after). When running our driver control op mode as well, we get around 1/2 to 1 second of delay on all movements. Reverting to v8.0 seems to fix the problem.

[NoahAndrews]

Does updating back to 8.1.1 cause the issue again? Are you updating the RC by updating your Android Studio project, or installing the prebuilt app?

[Robocoder9000]

Updating to 8.1.1 does cause the issue. We use the REV Hardware Client to update the RC.

[AlecHub]

With regards to the delay, are you using Iterative OpMode or Linear OpMode?

[Robocoder9000]

If by Iterative OpMode you mean a while op mode is active loop, then we're using that one. We code our driver control in Blocks and our auto with Android Studio, if that helps any.

[AlecHub]

Iterative is a class that extends the OpMode class. Every other OpMode is the Linear type.

[Robocoder9000]

Oh, well in that case I'm pretty sure we're using Linear op mode.

[NoahAndrews]

Can you share your TeleOp program?

[NoahAndrews]

We use the REV Hardware Client to update the RC.

We code our... auto with Android Studio, if that helps any.

If you use Android Studio, you need to update the RC by updating your Android Studio project. Updating the RC via the REV Hardware Client will remove any Op Modes developed in Android Studio (and it will display a warning about this on the update page).

[Robocoder9000]

Yeah, we redownload our code after updating the hub- Is that what you're talking about? edit: I'll share my code tonight, I don't have access right now. Thanks!

[texasdiaz]

@Robocoder9000 What @NoahAndrews is trying to tell you is that when you develop Android Studio code, you're not just updating and uploading Team Code. What you're downloading from the FtcRobotController GitHub Repo, and what you're writing Team Code for, is an actual copy of the Robot Controller Application. Each time you push "code" using Android Studio, you're actually building a Robot Controller App APK with your Team Code embedded inside it and pushing it to the Control Hub, where you're installing your own version of the Robot Controller App with your Team Code embedded within it. See, there's a difference between Android Studio and Blocks/OnBot Java teams in that:

Android Studio Teams:

1. Edit Team Code EMBEDDED WITHIN the Robot Controller App built using their Android Studio Code.
2. Upload the Robot Controller App to the Control Hub, which then replaces any existing Robot Controller App on the device. Each code upload is a full Build/Push/Install process on the Control Hub.
3. They should NEVER use the REV Hardware Client to update the Robot Controller App, as this will replace their custom Robot Controller App with their Team Code EMBEDDED within it with a DEFAULT Robot Controller App.
4. In order to update the Robot Controller App code, Android Studio teams MUST merge code from the FtcRobotController GitHub Repository into their code in order to get Robot Controller App updates.

Blocks and OnBot Java Teams:

1. Edit Team Code that lives ALONGSIDE the Robot Controller App.
2. When Blocks code is edited, it is automatically built/compiled on Save.
3. When OnBot Java code is edited, it is built/compiled when you build the code.
4. They can use the REV Hardware Client to update the Robot Controller App on their Control Hubs (or phones) because they just use the default Robot Controller App, and their code is unaffected by a Robot Controller App update.

So hopefully now you understand that you shouldn't be "updating the Robot Controller App" using the REV Hardware Client if you're an Android Studio team. You probably thought you were just uploading Robot Code to the controller, like OnBot Java and Blocks teams can do, but it's a lot more complex than that.

[Lunerwalker2]

I'm not sure if this is already called out somewhere, but the confusion that updating the SDK version when using Android Studio cannot be done via the Hardware Client (and the associated pop-up in AS that says you are going to "overwrite a previous version of the app" ) has been a very common problem for many inexperienced programmers.

It is by far one of the most common questions in the community (especially in the FTC Discord), probably since there's not many places that clearly point it out (like in the hardware client itself).

[AlecHub]

We use Android Studio thus we can't use REV Hardware Client to update the Robot Controller App. We update the Driver Station App by downloading the Driver Station APK from GitHub directly onto the Driver Station phone (i.e. navigate to Releases from the phone, then click/tap on the APK you want to download to the phone, then install the APK). Bypassing the REV Hardware Client avoids mistakes [in our scenario].

[Lunerwalker2]

For the Driver Station app, the REV Hardware Client makes the updating process quite easy, and I have no problems with the functionality.

What is a problem however, is that the option to update the RC app also is in the client with no callout or notice that it is not the intended update method for Android Studio users. This leaves many people confused when their version is overwritten after they next push code from Android Studio.

This isn't really a problem centered on the client specifically; there is a general lack of documentation surrounding the RC app update process for Android Studio users.

For example, nowhere on this page is it mentioned: https://docs.revrobotics.com/duo-control/managing-the-control-system/updating-robot-controller-application

And the SDK wiki page on updating the app doesn't offer any help either:

[texasdiaz]

If you're going to be frustrated, let's be frustrated about the right things.

What is a problem however, is that the option to update the RC app also is in the client with no callout or notice that it is not the intended update method for Android Studio users. This leaves many people confused when their version is overwritten after they next push code from Android Studio.

I won't say this isn't the case for you, but at least for me there's a massive in-your-face warning in my Hardware Client (I have the latest Hardware Client, 1.4.3) regarding Android Studio once I install an Android Studio project to my Control Hub:

I do not know if this message is limited to the Control Hub, or if it also shows up for an Android Phone (I don't have one handy to check, sorry) but this seems pretty open and honest about this policy. I'm curious what version of the REV Hardware Client you're using and your specific hardware.

This isn't really a problem centered on the client specifically; there is a general lack of documentation surrounding the RC app update process for Android Studio users.

You're right, and now that we have the ftc-docs platform we've been pushing massive amounts of documentation to the community - the current SDK documentation is just a taste of that. This is an area that we'd love to tackle once we have more resources to do so. Members of the community are also welcome to submit PRs for ftc-docs, and we'll evaluate and work with PR submitters. We even have a small list of "we'd love to document ..." which we can share with interested parties who would like to help out.

However, I'd like to dispel a common myth. Android Studio has never been a platform that FTC has ever recommended to those who do not have strong programming mentors with experience with Java, Git, and other technologies. If you don't have the know-how to pull and merge changes from a forked or cloned repository in Git, the only option you have is the way you created your branch the first time - pull a new version, float your team code into the new version, and build. While that's a massive pain in the rump, it's tried and true. Even when there is documentation for a recommended method to update using git, it will very likely not cover however you forked/cloned/downloaded the repository, and you'll likely want to start from scratch anyway. It also won't help people who bork their repo by doing dumb things (usually by accident) in the process of trying to update without necessary mentorship. But you're completely right, getting more documentation will at least improve the visibility of the issue. I also fear it will embolden others who still have not the resources or experience to "jump into the deep end" - but that's for another day.

-Danny

[alan412]

Danny, How does one issue a PR for ftc-docs? I have had several teams ask me if I would add a chapter to my book ( https://github.com/alan412/LearnJavaForFTC ) on a recommended way for setting up git for a team. Personally I would rather do it as part of ftc-docs as it feels to me to be out of the scope of the book.

Thanks,

Alan

On Mon, Jan 2, 2023 at 12:52 AM Danny Diaz @.***> wrote:

If you're going to be frustrated and angry, let's be frustrated and angry about the right things.

What is a problem however, is that the option to update the RC app also is in the client with no callout or notice that it is not the intended update method for Android Studio users. This leaves many people confused when their version is overwritten after they next push code from Android Studio.

I won't say this isn't the case for you, but at least for me there's a massive in-your-face warning in my Hardware Client (I have the latest Hardware Client, 1.4.3) regarding Android Studio once I install an Android Studio project to my Control Hub:

[image: image] https://user-images.githubusercontent.com/5846611/210197766-3ccac111-b71c-42a6-93ab-19b33246055b.png

I do not know if this message is limited to the Control Hub, or if it also shows up for an Android Phone (I don't have one handy to check, sorry) but this seems pretty open and honest about this policy. I'm curious what version of the REV Hardware Client you're using and your specific hardware.

This isn't really a problem centered on the client specifically; there is a general lack of documentation surrounding the RC app update process for Android Studio users.

You're right, and now that we have the ftc-docs platform http://ftc-docs.firstinspires.org/ we've been pushing massive amounts of documentation to the community - the current SDK documentation is just a taste of that. This is an area that we'd love to tackle once we have more resources to do so. Members of the community are also welcome to submit PRs for ftc-docs, and we'll evaluate and work with PR submitters. We even have a small list of "we'd love to document ..." which we can share with interested parties who would like to help out.

However, I'd like to dispel a common myth. Android Studio has never been a platform that FTC has ever recommended to those who do not have strong programming mentors with experience with Java, Git, and other technologies. If you don't have the know-how to pull and merge changes from a forked or cloned repository in Git, the only option you have is the way you created your branch the first time - pull a new version, float your team code into the new version, and build. While that's a massive pain in the rump, it's tried and true. Even when there is documentation for a recommended method to update using git, it will very likely not cover however you forked/cloned/downloaded the repository, and you'll likely want to start from scratch anyway. It also won't help people who bork their repo by doing dumb things (usually by accident) in the process of trying to update without necessary mentorship. But you're completely right, getting more documentation will at least improve the visibility of the issue. I also fear it will embolden others who still have not the resources or experience to "jump into the deep end" - but that's for another day.

-Danny

— Reply to this email directly, view it on GitHub https://github.com/FIRST-Tech-Challenge/FtcRobotController/issues/529#issuecomment-1368673018, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAF3Y77GHYULKYXI73R674TWQJUIRANCNFSM6AAAAAAS736SQQ . You are receiving this because you are subscribed to this thread.Message ID: @.*** com>

[texasdiaz]

Hey Alan,

I couldn't agree more. Submitting a PR is the easy part, assuming you already know how to create reStructured Text documents and understand how to submit into the ftc-docs infrastructure. We have the exact same internal architecture as wpi-lib, and I would assume we're pretty similar to GM0. I guess it's infinitely easier to update an existing document than adding/creating new documents.

Speaking of, we've actually started a "Recommended Android Studio/git process" document, we just didn't have a target release date (and didn't want to get anyone depending on it). We've decided to prioritize the document - this just means it'll get done sooner, but we still don't have a target date; we're hoping in the next few weeks. I would appreciate if you'd review it once it's made, to see if there are additional points of view to add to it.

-Danny

[alan412]

Is it this repo: FIRST-Tech-Challenge/ftcdocs?

If so, I can start on one as well with the information we have for new students when they join our team.

--Alan

On Mon, Jan 2, 2023 at 7:51 PM Danny Diaz @.***> wrote:

Hey Alan,

I couldn't agree more. Submitting a PR is the easy part, assuming you already know how to create reStructured Text documents and understand how to submit into the ftc-docs infrastructure. We have the exact same internal architecture as wpi-lib, and I would assume we're pretty similar to GM0. I guess it's infinitely easier to update an existing document than adding/creating new documents.

Speaking of, we've actually started a "Recommended Android Studio/git process" document, we just didn't have a target release date (and didn't want to get anyone depending on it). We've decided to prioritize the document - this just means it'll get done sooner, but we still don't have a target date; we're hoping in the next few weeks. I would appreciate if you'd review it once it's made, to see if there are additional points of view to add to it.

-Danny

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[texasdiaz]

Yup, that's the one.

Thanks!

-Danny

[Lunerwalker2]

I won't say this isn't the case for you, but at least for me there's a massive in-your-face warning in my Hardware Client (I have the latest Hardware Client, 1.4.3) regarding Android Studio once I install an Android Studio project to my Control Hub:

Thank you for correcting me on this; I did not fully confirm that fact before saying it, and after checking with my own team's Control Hub, I too, see that message. Perhaps I had remembered a far previous version of the client, but I may have just overlooked it altogether. Either way, it was incorrect of me to criticize.

However, I'd like to dispel a common myth. Android Studio has never been a platform that FTC has ever recommended to those who do not have strong programming mentors with experience with Java, Git, and other technologies.

I don't think it's a myth that it's not encouraged, and that's totally fine. Android studio has a learning curve to it that can make the experience frustrating at first. That being said, I don't think that it is limited to team who have experienced programming mentors. There are very few teams who have programming mentors, or even mentors experienced in software, yet the amount of teams who successfully use Android Studio is immense. The issue that I see, at least in my region, is that teams start off with Onbot Java or Blocks, and are afraid to switch away from it despite having all the experience and knowledge needed to.

This is unfortunate, especially in the case of OnBot Java users, where much of the learning curve (actually learning how to program FTC things in Java) has already been climbed, with smaller issues like updating the SDK being deterrents (although there are often other external factors like access to devices capable of running AS).

One way or another, my concerns don't belong in this thread, so I'll stop pushing the topic. I didn't intend any disrespect to the people volunteering their time for this competition. Knowing there is work in the pipeline to improve the documentation is great to know, and I look forward to seeing it progress!